home *** CD-ROM | disk | FTP | other *** search
Text File | 1997-11-03 | 137.4 KB | 3,550 lines |
- Linux AX25-HOWTO, Amateur Radio.
- Terry Dawson, VK2KTJ, terry@perf.no.itg.telstra.com.au
- v1.5, 17 October 1997
-
- The Linux Operating System is perhaps the only operating system in the
- world that can boast native and standard support for the AX.25 packet
- radio protocol utilised by Amateur Radio Operators worldwide. This
- document aims to describe how to install and configure this support.
-
- 1. Introduction.
-
- This document was originally an appendix to the HAM-HOWTO, but grew
- too large to be reasonably managed in that fashion. This document
- describes how to install and configure the native AX.25, NetRom and
- Rose support for Linux. A few typical configurations are described
- that could be used as models to work from.
-
- The Linux implementation of the amateur radio protocols is very
- flexible. To people relatively unfamiliar with the Linux operating
- system the configuration process may look daunting and complicated. It
- will take you a little time to come to understand how the whole thing
- fits together. You will find configuration very difficult if you have
- not properly prepared yourself by learning about Linux in general. You
- cannot expect to switch from some other environment to Linux without
- learning about Linux itself.
-
- 1.1. Changes from the previous version
-
- Additions:
- Joerg Reuters Web Page
- "More Information" section
- ax25ipd configuration.
-
- Corrections/Updates:
- Changed pty's to a safer range to prevent possible conflicts
- Updated module and ax25-utils versions.
-
- ToDo:
- Fix up the SCC section, this is probably wrong.
- Expand on the programming section.
-
- 1.2. Where to obtain new versions of this document.
-
- The best place to obtain the latest version of this document is from a
- Linux Documentation Project archive. The Linux Documentation Project
- runs a Web Server and this document appears there as the AX25-HOWTO
- <http://sunsite.unc.edu/LDP/HOWTO/AX25-HOWTO.html>. This document is
- also available in various formats from the sunsite.unc.edu ftp archive
- <ftp://sunsite.unc.edu/pub/Linux/docs/howto/>.
-
- You can always contact me, but I pass new versions of the document
- directly to the LDP HOWTO coordinator, so if it isn't there then
- chances are I haven't finished it.
-
- 1.3. Other related documentation.
-
- There is a lot of related documentation. There are many documents that
- relate to Linux networking in more general ways and I strongly
- recommend you also read these as they will assist you in your efforts
- and provide you with stronger insight into other possible
- configurations.
-
- They are:
-
- The HAM-HOWTO <http://sunsite.unc.edu/LDP/HOWTO/HAM-HOWTO.html>,
-
- the NET-3-HOWTO <http://sunsite.unc.edu/LDP/HOWTO/NET-3-HOWTO.html>,
-
- the Ethernet-HOWTO <http://sunsite.unc.edu/LDP/HOWTO/Ethernet-
- HOWTO.html>,
-
- and:
-
- the Firewall-HOWTO <http://sunsite.unc.edu/LDP/HOWTO/Firewall-
- HOWTO.html>
-
- More general Linux information may be found by reference to other
- Linux HOWTO <http://sunsite.unc.edu/LDP/HOWTO/> documents.
-
- 2. The Packet Radio Protocols and Linux.
-
- The AX.25 protocol offers both connected and connectionless modes of
- operation, and is used either by itself for point-point links, or to
- carry other protocols such as TCP/IP and NetRom.
-
- It is similar to X.25 level 2 in structure, with some extensions to
- make it more useful in the amateur radio environment.
-
- The NetRom protocol is an attempt at a full network protocol and uses
- AX.25 at its lowest layer as a datalink protocol. It provides a
- network layer that is an adapted form of AX.25. The NetRom protocol
- features dynamic routing and node aliases.
-
- The Rose protocol was conceived and first implemented by Tom Moulton
- W2VY and is an implementation of the X.25 packet layer protocol and is
- designed to operate with AX.25 as its datalink layer protocol. It too
- provides a network layer. Rose addresses take the form of 10 digit
- numbers. The first four digits are called the Data Network
- Identification Code (DNIC) and are taken from Appendix B of the CCITT
- X.121 recommendation. More information on the Rose protocol may be
- ontained from the RATS Web server <http://www.rats.org/>.
-
- Alan Cox developed some early kernel based AX.25 software support for
- Linux. Jonathon Naylor <g4klx@g4klx.demon.co.uk> has taken up ongoing
- development of the code, has added NetRom and Rose support and is now
- the developer of the AX.25 related kernel code. DAMA support was
- developed by Joerg, DL1BKE, jreuter@poboxes.com. Baycom and SoundModem
- support were added by Thomas Sailer, <sailer@ife.ee.ethz.ch>. The
- AX.25 utility software is now maintained by me.
-
- The Linux code supports KISS based TNC's (Terminal Node Controllers),
- the Ottawa PI card, the Gracilis PacketTwin card and other Z8530 SCC
- based cards with the generic SCC driver and both the Parallel and
- Serial port Baycom modems. Thomas's new soundmodem driver supports
- Soundblaster and soundcards based on the Crystal chipset.
-
- The User programs contain a simple PMS (Personal Message System), a
- beacon facility, a line mode connect program, `listen' an example of
- how to capture all AX.25 frames at raw interface level and programs to
- configure the NetRom protocol. Included also are an AX.25 server style
- program to handle and despatch incoming AX.25 connections and a NetRom
- daemon which does most of the hard work for NetRom support.
-
- 2.1. How it all fits together.
-
- The Linux AX.25 implementation is a brand new implementation. While in
- many ways it may looks similar to NOS, or BPQ or other AX.25
- implementations, it is none of these and is not identical to any of
- them. The Linux AX.25 implementation is capable of being configured to
- behave almost identically to other implementations, but the
- configuration process is very different.
-
- To assist you in understanding how you need to think when configuring
- this section describes some of the structural features of the AX.25
- implementation and how it fits into the context of the overall Linux
- structure.
-
- Simplified Protocol Layering Diagram
-
- -----------------------------------------------
- | AF_AX25 | AF_NETROM | AF_INET | AF_ROSE |
- |=========|===========|=============|=========|
- | | | | |
- | | | TCP/IP | |
- | | ---------- | |
- | | NetRom | | Rose |
- | -------------------------------------
- | AX.25 |
- -----------------------------------------------
-
- This diagram simply illustrates that NetRom, Rose and TCP/IP all run
- directly on top of AX.25, but that each of these protocols is treated
- as a seperate protocol at the programming interface. The `AF_' names
- are simply the names given to the `Address Family' of each of these
- protocols when writing programs to use them. The important thing to
- note here is the implicit dependence on the configuration of your
- AX.25 devices before you can configure your NetRom, Rose or TCP/IP
- devices.
-
- Software module diagram of Linux Network Implementation
-
- ----------------------------------------------------------------------------
- User | Programs | call node || Daemons | ax25d mheardd
- | | pms mheard || | inetd netromd
- ----------------------------------------------------------------------------
- | Sockets | open(), close(), listen(), read(), write(), connect()
- | |------------------------------------------------------
- | | AF_AX25 | AF_NETROM | AF_ROSE | AF_INET
- |------------------------------------------------------------------
- Kernel | Protocols | AX.25 | NetRom | Rose | IP/TCP/UDP
- |------------------------------------------------------------------
- | Devices | ax0,ax1 | nr0,nr1 | rose0,rose1 | eth0,ppp0
- |------------------------------------------------------------------
- | Drivers | Kiss PI2 PacketTwin SCC BPQ | slip ppp
- | | Soundmodem Baycom | ethernet
- ----------------------------------------------------------------------------
- Hardware | PI2 Card, PacketTwin Card, SCC card, Serial port, Ethernet Card
- ----------------------------------------------------------------------------
-
- This diagram is a little more general than the first. This diagram
- attempts to show the relationship between user applications, the ker¡
- nel and the hardware. It also shows the relationship between the
- Socket application programming interface, the actual protocol modules,
- the kernel networking devices and the device drivers. Anything in this
- diagram is dependent on anything underneath it, and in general you
- must configure from the bottom of the diagram upwards. So for exam¡
- ple, if you want to run the call program you must also configure the
- Hardware, then ensure that the kernel has the appropriate device
- driver, that you create the appropriate network device, that the ker¡
- nel includes the desired protocol that presents a programming inter¡
- face that the call program can use. I have attempted to lay out this
- document in roughly that order.
-
- 3. The AX.25/NetRom/Rose software components.
-
- The AX.25 software is comprised of three components, the kernel
- source, the network configuration tools and the utility programs.
-
- The version 2.0.xx Linux kernels include the AX.25, NetRom, Z8530 SCC,
- PI card and PacketTwin drivers by default. These have been
- significantly enhanced in the 2.1.* kernels. Unfortunately, the rest
- of the 2.1.* kernels makes them fairly unstable at the moment and not
- a good choice for a production system. To solve this problem Jonathon
- Naylor has prepared a patch kit which will bring the amateur radio
- protocol support in a 2.0.28 kernel up to the standard of the 2.1.*
- kernels. This is very simple to apply, and provides a range of
- facilities not present in the standard kernel such as Rose support.
-
- 3.1. Finding the kernel, tools and utility packages.
-
- 3.1.1. The kernel source:
-
- The kernel source can be found in its usual place at: ftp.kernel.org
-
- /pub/linux/kernel/v2.0/linux-2.0.31.tar.gz
-
- The current version of the AX25 upgrade patch is available at:
- ftp.pspt.fi
-
- /pub/linux/ham/ax25/ax25-module-14e.tar.gz
-
- 3.1.2. The network tools:
-
- The latest alpha release of the standard Linux network tools support
- AX.25 and NetRom and can be found at: ftp.inka.de
-
- /pub/comp/Linux/networking/net-tools/net-tools-1.33.tar.gz
-
- The latest ipfwadm package can be found at: ftp.xos.nl
-
- /pub/linux/ipfwadm/
-
- 3.1.3. The AX25 utilities:
-
- There are two different families of AX25-utilities. One is for the
- 2.0.* kernels and the other will work with either the 2.1.* kernels
- or the 2.0.*+moduleXX kernels. The ax25-utils version number indicates
- the oldest version of kernel that they will work with. Please choose a
- version of the ax25-utils appropriate to your kernel. The following
- are working combinations. You must use one of the following
- combinations, any other combination will not work, or will not work
- well.
-
- Linux Kernel AX25 Utility set
- ---------------------- -------------------------
- linux-2.0.29 ax25-utils-2.0.12c.tar.gz **
- linux-2.0.28+module12 ax25-utils-2.1.22b.tar.gz **
- linux-2.0.30+module14c ax25-utils-2.1.42a.tar.gz
- linux-2.0.31+module14d ax25-utils-2.1.42a.tar.gz
- linux-2.1.22 ++ ax25-utils-2.1.22b.tar.gz
- linux-2.1.42 ++ ax25-utils-2.1.42a.tar.gz
-
- Note: the ax25-utils-2.0.* series (marked above with the '**' symbol)
- is now obsolete and is no longer supported. This document covers
- configuration using the versions of software recommended above the
- table. While there are differences between the releases, most of the
- information will be relevant to earlier releases of code.
-
- The AX.25 utility programs can be found at: ftp.pspt.fi
- <ftp://ftp.pspt.fi/pub/linux/ham/ax25/>
-
- or at: sunsite.unc.edu <ftp://sunsite.unc.edu/pub/Linux/apps/ham/>
-
- 4. Installing the AX.25/NetRom/Rose software.
-
- To successfully install AX.25 support on your linux system you must
- configure and install an appropriate kernel and then install the AX.25
- utilities.
-
- 4.1. Compiling the kernel.
-
- If you are already familiar with the process of compiling the Linux
- Kernel then you can skip this section, just be sure to select the
- appropriate options when compiling the kernel. If you are not, then
- read on.
-
- The normal place for the kernel source to be unpacked to is the
- /usr/src directory into a subdirectory called linux. To do this you
- should be logged in as root and execute a series of commands similar
- to the following:
-
- # mv linux linux.old
- # cd /usr/src
- # tar xvfz linux-2.0.31.tar.gz
- # tar xvfz /pub/net/ax25/ax25-module-14e.tar.gz
- # patch -p0 </usr/src/ax25-module-14/ax25-2.0.31-2.1.47-2.diff
- # cd linux
-
- After you have unpacked the kernel source and applied the upgrade, you
- need to run the configuration script and choose the options that suit
- your hardware configuration and the options that you wish built into
- your kernel. You do this by using the command:
-
- # make menuconfig
-
- You might also try:
-
- # make config
-
- I'm going to describe the full screen method (menuconfig) because it
- is easier to move around, but you use whichever you are most
- comfortable with.
-
- In either case you will be offered a range of options at which you
- must answer `Y' or `N'. (Note you may also answer `M' if you are using
- modules. For the sake of simplicity I will assume you are not, please
- make appropriate modifications if you are).
-
- The options most relevant to an AX.25 configuration are:
-
- Code maturity level options --->
- ...
- [*] Prompt for development and/or incomplete code/drivers
- ...
- General setup --->
- ...
- [*] Networking support
- ...
- Networking options --->
- ...
- [*] TCP/IP networking
- [?] IP: forwarding/gatewaying
- ...
- [?] IP: tunneling
- ...
- [?] IP: Allow large windows (not recommended if <16Mb of memory)
- ...
- [*] Amateur Radio AX.25 Level 2
- [?] Amateur Radio NET/ROM
- [?] Amateur Radio X.25 PLP (Rose)
- ...
- Network device support --->
- [*] Network device support
- ...
- [*] Radio network interfaces
- [?] BAYCOM ser12 and par96 driver for AX.25
- [?] Soundcard modem driver for AX.25
- [?] Soundmodem support for Soundblaster and compatible cards
- [?] Soundmodem support for WSS and Crystal cards
- [?] Soundmodem support for 1200 baud AFSK modulation
- [?] Soundmodem support for 4800 baud HAPN-1 modulation
- [?] Soundmodem support for 9600 baud FSK G3RUH modulation
- [?] Serial port KISS driver for AX.25
- [?] BPQ Ethernet driver for AX.25
- [?] Gracilis PackeTwin support for AX.25
- [?] Ottawa PI and PI/2 support for AX.25
- [?] Z8530 SCC KISS emulation driver for AX.25
- ...
-
- The options I have flagged with a `*' are those that you must must
- answer `Y' to. The rest are dependent on what hardware you have and
- what other options you want to include. Some of these options are
- described in more detail later on, so if you don't know what you want
- yet, then read ahead and come back to this step later.
-
- After you have completed the kernel configuration you should be able
- to cleanly compile your new kernel:
-
- # make dep
- # make clean
- # make zImage
-
- maake sure you move your arch/i386/boot/zImage file wherever you want
- it and then edit your /etc/lilo.conf file and rerun lilo to ensure
- that you actually boot from it.
-
- 4.1.1. A word about Kernel modules
-
- I recommend that you don't compile any of the drivers as modules. In
- nearly all installations you gain nothing but additional complexity.
- Many people have problems trying to get the modularised components
- working, not because the software is faulty but because modules are
- more complicated to install and configure.
-
- If you've chosen to compile any of the components as modules, then
- you'll also need to use:
-
- # make modules
- # make modules_install
-
- to install your modules in the appropriate location.
-
- You will also need to add some entries into your /etc/conf.modules
- file that will ensure that the kerneld program knows how to handle the
- kernel modules. You should add/modify the following:
-
- alias net-pf-3 ax25
- alias net-pf-6 netrom
- alias net-pf-11 rose
- alias tty-ldisc-1 slip
- alias tty-ldisc-3 ppp
- alias tty-ldisc-5 mkiss
- alias bc0 baycom
- alias nr0 netrom
- alias pi0a pi2
- alias pt0a pt
- alias scc0 optoscc (or one of the other scc drivers)
- alias sm0 soundmodem
- alias tunl0 newtunnel
- alias char-major-4 serial
- alias char-major-5 serial
- alias char-major-6 lp
-
- 4.1.2. What's new in 2.0.*+ModuleXX or 2.1.* Kernels ?
-
- The 2.1.* kernels have enhanced versions of nearly all of the
- protocols and drivers. The most significant of the enhancements are:
-
- modularised
- the protocols and drivers have all been modularised so that you
- can insmod and rmmod them whenever you wish. This reduces the
- kernel memory requirements for infrequently used modules and
- makes development and bug hunting much simpler. That being said,
- it also makes configuration slightly more difficult.
-
- All drivers are now network drivers
- all of the network devices such as Baycom, SCC, PI, Packettwin
- etc now present a normal network interface, that is they now
- look like the ethernet driver does, they no longer look like
- KISS TNC's. A new utility called net2kiss allows you to build a
- kiss interface to these devices if you wish.
- bug fixed
- there have been many bug fixes and new features added to the
- drivers and protocols. The Rose protocol is one important
- addition.
-
- 4.2. The network configuration tools.
-
- Now that you have compiled the kernel you should compile the new
- network configuration tools. These tools allow you to modify the
- configuration of network devices and to add routes to the routing
- table.
-
- The new alpha release of the standard net-tools package includes
- support for AX.25 and NetRom support. I've tested this and it seems to
- work well for me.
-
- 4.2.1. A patch kit that adds Rose support and fixes some bugs.
-
- The standard net-tools-1.33.tar.gz package has some small bugs that
- affect the AX.25 and NetRom support. I've made a small patch kit that
- corrects these and adds Rose support to the tools as well.
-
- You can get the patch from: zone.pspt.fi
- <ftp://zone.pspt.fi/pub/linux/ham/ax25/net-
- tools-1.33.rose.tjd.diff.gz>.
-
- 4.2.2. Building the standard net-tools release.
-
- Don't forget to read the Release file and follow any instructions
- there. The steps I used to compile the tools were:
-
- # cd /usr/src
- # tar xvfz net-tools-1.33.tar.gz
- # zcat net-tools-1.33.rose.tjd.diff.gz | patch -p0
- # cd net-tools-1.33
- # make config
-
- At this stage you will be presented with a series of configuration
- questions, similar to the kernel configuration questions. Be sure to
- include support for all of the protocols and network devices types
- that you intend to use. If you do not know how to answer a particular
- question then answer `Y'.
-
- When the compilation is complete, you should use the:
-
- # make install
-
- command to install the programs in their proper place.
-
- If you wish to use the IP firewall facilities then you will need the
- latest firewall administration tool ipfwadm. This tool replaces the
- older ipfw tool which will not work with new kernels.
-
- I compiled the ipfwadm utility with the following commands:
-
- # cd /usr/src
- # tar xvfz ipfwadm-2.0beta2.tar.gz
- # cd ipfwadm-2.0beta2
- # make install
- # cp ipfwadm.8 /usr/man/man8
- # cp ipfw.4 /usr/man/man4
-
- 4.3. The AX.25 user and utility programs.
-
- After you have successfully compiled and booted your new kernel, you
- need to compile the user programs. To compile and install the user
- programs you should use a series of commands similar to the following:
-
- # cd /usr/src
- # tax xvfz ax25-utils-2.1.42a.tar.gz
- # cd ax25-utils-2.1.42a
- # make config
- # make
- # make install
-
- The files will be installed under the /usr directory by default in
- subdirectories: bin, sbin, etc and man.
-
- If this is a first time installation, that is you've never installed
- any ax25 utilities on your machine before you should also use the:
-
- # make installconf
-
- command to install some sample configuration files into the /etc/ax25/
- directory from which to work.
-
- If you get messages something like:
-
- gcc -Wall -Wstrict-prototypes -O2 -I../lib -c call.c
- call.c: In function `statline':
- call.c:268: warning: implicit declaration of function `attron'
- call.c:268: `A_REVERSE' undeclared (first use this function)
- call.c:268: (Each undeclared identifier is reported only once
- call.c:268: for each function it appears in.)
-
- then you should double check that you have the ncurses package
- properly installed on your system. The configuration script attempts
- to locate your ncurses packages in the common locations, but some
- installations have ncurses badly installed and it is unable to locate
- them.
- 5. A note on callsigns, addresses and things before we start.
-
- Each AX.25 and NetRom port on your system must have a callsign/ssid
- allocated to it. These are configured in the configuration files that
- will be described in detail later on.
-
- Some AX.25 implementations such as NOS and BPQ will allow you to
- configure the same callsign/ssid on each AX.25 and NetRom port. For
- somewhat complicated technical reasons Linux does not allow this. This
- isn't as big a problem in practise as it might seem.
-
- This means that there are things you should be aware of and take into
- consideration when doing your configurations.
-
- 1. Each AX.25 and NetRom port must be configured with a unique
- callsign/ssid.
-
- 2. TCP/IP will use the callsign/ssid of the AX.25 port it is being
- transmitted or received by, ie the one you configured for the AX.25
- interface in point 1.
-
- 3. NetRom will use the callsign/ssid specified for it in its
- configuration file, but this callsign is only used when your NetRom
- is speaking to another NetRom, this is not the callsign/ssid that
- AX.25 users who wish to use your NetRom `node' will use. More on
- this later.
-
- 4. Rose will, by default, use the callsign/ssid of the AX.25 port,
- unless the Rose callsign has been specifically set using the
- `rsparms' command. If you set a callsign/ssid using the `rsparms'
- command then Rose will use this callsign/ssid on all ports.
-
- 5. Other programs, such as the `ax25d' program can listen using any
- callsign/ssid that they wish and these may be duplicated across
- different ports.
-
- 6. If you are careful with routing you can configure the same IP
- address on all ports if you wish.
-
- 5.1. What are all those T1, T2, N2 and things ?
-
- Not every AX.25 implementation is a TNC2. Linux uses nomenclature that
- differs in some respects from that you will be used to if your sole
- experience with packet is a TNC. The following table should help you
- interpret what each of the configurable items are, so that when you
- come across them later in this text you'll understand what they mean.
-
- -------------------------------------------------------------------
- Linux | TAPR TNC | Description
- -------------------------------------------------------------------
- T1 | FRACK | How long to wait before retransmitting an
- | | unacknowledged frame.
- -------------------------------------------------------------------
- T2 | RESPTIME | The minimum amount of time to wait for another
- | | frame to be received before transmitting
- | | an acknowledgement.
- -------------------------------------------------------------------
- T3 | CHECK | The period of time we wait between sending
- | | a check that the link is still active.
- -------------------------------------------------------------------
- N2 | RETRY | How many times to retransmit a frame before
- | | assuming the connection has failed.
- -------------------------------------------------------------------
- Idle | | The period of time a connection can be idle
- | | before we close it down.
- -------------------------------------------------------------------
- Window | MAXFRAME | The maximum number of unacknowledged
- | | transmitted frames.
- -------------------------------------------------------------------
-
- 5.2. Run time configurable parameters
-
- The 2.1.* and 2.0.* +moduleXX kernels have a new feature that allows
- you to change many previously unchangable parameters at run time. If
- you take a careful look at the /proc/sys/net/ directory structure you
- will see many files with useful names that describe various parameters
- for the network configuration. The files in the /proc/sys/net/ax25/
- directory each represents one configured AX.25 port. The name of the
- file relates to the name of the port.
-
- The structure of the files in /proc/sys/net/ax25/<portname>/ is as
- follows:
-
- FileName Meaning Values Default
- ip_default_mode IP Default Mode 0=DG 1=VC 0
- ax25_default_mode AX.25 Default Mode 0=Normal 1=Extended 0
- backoff_type Backoff 0=Linear 1=Exponential 1
- connect_mode Connected Mode 0=No 1=Yes 1
- standard_window_size Standard Window 1 <= N <= 7 2
- extended_window_size Extended Window 1 <= N <= 63 32
- t1_timeout T1 Timeout 1s <= N <= 30s 10s
- t2_timeout T2 Timeout 1s <= N <= 20s 3s
- t3_timeout T3 Timeout 0s <= N <= 3600s 300s
- idle_timeout Idle Timeout 0m <= N 20m
- maximum_retry_count N2 1 <= N <= 31 10
- maximum_packet_length AX.25 Frame Length 1 <= N <= 512 256
-
- In the table T1, T2 and T3 are given in seconds, and the Idle Timeout
- is given in minutes. But please note that the values used in the
- sysctl interface are given in internal units where the time in seconds
- is multiplied by 10, this allows resolution down to 1/10 of a second.
- With timers that are allowed to be zero, eg T3 and Idle, a zero value
- indicates that the timer is disabled.
-
- The structure of the files in /proc/sys/net/netrom/ is as follows:
-
- FileName Values Default
- default_path_quality 10
- link_fails_count 2
- network_ttl_initialiser 16
- obsolescence_count_initialiser 6
- routing_control 1
- transport_acknowledge_delay 50
- transport_busy_delay 1800
- transport_maximum_tries 3
- transport_requested_window_size 4
- transport_timeout 1200
-
- The structure of the files in /proc/sys/net/rose/ is as follows:
-
- FileName Values Default
- acknowledge_hold_back_timeout 50
- call_request_timeout 2000
- clear_request_timeout 1800
- link_fail_timeout 1200
- maximum_virtual_circuits 50
- reset_request_timeout 1800
- restart_request_timeout 1800
- routing_control 1
- window_size 3
-
- To set a parameter all you need to do is write the desired value to
- the file itself, for example to check and set the Rose window size
- you'd use something like:
-
- # cat /proc/sys/net/rose/window_size
- 3
- # echo 4 >/proc/sys/net/rose/window_size
- # cat /proc/sys/net/rose/window_size
- 4
-
- 6. Configuring an AX.25 port.
-
- Each of the AX.25 applications read a particular configuration file to
- obtain the parameters for the various AX.25 ports configured on your
- Linux machine. For AX.25 ports the file that is read is the
- /etc/ax25/axport file. You must have an entry in this file for each
- AX.25 port you want on your system.
-
- 6.1. Creating the AX.25 network device.
-
- The network device is what is listed when you use the `ifconfig'
- command. This is the object that the Linux kernel sends and receives
- network data from. Nearly always the network device has a physical
- port associated with it, but there are occasions where this isn't
- necessary. The network device does relate directly to a device driver.
-
- In the Linux AX.25 code there are a number of device drivers. The most
- common is probably the KISS driver, but others are the SCC driver(s),
- the Baycom driver and the SoundModem driver.
- Each of these device drivers will create a network device when it is
- started.
-
- 6.1.1. Creating a KISS device.
-
- Kernel Compile Options:
-
- General setup --->
- [*] Networking support
- Network device support --->
- [*] Network device support
- ...
- [*] Radio network interfaces
- [*] Serial port KISS driver for AX.25
-
- Probably the most common configuration will be for a KISS TNC on a
- serial port. You will need to have the TNC preconfigured and
- connected to your serial port. You can use a communications program
- like minicom or seyon to configure the TNC into kiss mode.
-
- To create a KISS device you use the kissattach program. In it simplest
- form you can use the kissattach program as follows:
-
- # /usr/sbin/kissattach /dev/ttyS0 radio
- # kissparms -p radio -t 100 -s 100 -r 25
-
- The kissattach command will create a KISS network device. These
- devices are called `ax[0-9]'. The first time you use the kissattach
- command it creates `ax0', the second time it creates `ax1' etc. Each
- KISS device has an associated serial port.
-
- The kissparms command allows you to set various KISS parameters on a
- KISS device.
-
- Specifically the example presented would create a KISS network device
- using the serial device `/dev/ttyS0' and the entry from the
- /etc/ax25/axports with a port name of `radio'. It then configures it
- with a txdelay and slottime of 100 milliseconds and a ppersist value
- of 25.
-
- Please refer to the man pages for more information.
-
- 6.1.1.1. Configuring for Dual Port TNC's
-
- The mkiss utility included in the ax25-utils distribution allows you
- to make use of both modems on a dual port TNC. Configuration is fairly
- simple. It works by taking a single serial device connected to a
- single multiport TNC and making it look like a number of devices each
- connected to a single port TNC. You do this before you do any of the
- AX.25 configuration. The devices that you then do the AX.25
- configuration on are pseudo-TTY interfaces, (/dev/ttyq*), and not the
- actual serial device. Pseudo-TTY devices create a kind of pipe through
- which programs designed to talk to tty devices can talk to other
- programs designed to talk to tty devices. Each pipe has a master and a
- slave end. The master end is generally called `/dev/ptyq*' and the
- slave ends are called `/dev/ttyq*'. There is a one to one relationship
- between masters and slaves, so /dev/ptyq0 is the master end of a pipe
- with /dev/ttyq0 as its slave. You must open the master end of a pipe
- before opening the slave end. mkiss exploits this mechanism to split a
- single serial device into seperate devices.
-
- Example: if you have a dual port tnc and it is connected to your
- /dev/ttyS0 serial device at 9600 bps, the command:
-
- # /usr/sbin/mkiss -s 9600 /dev/ttyS0 /dev/ptyq0 /dev/ptyq1
- # /usr/sbin/kissattach /dev/ttyq0 port1
- # /usr/sbin/kissattach /dev/ttyq1 port2
-
- would create two pseudo-tty devices that each look like a normal
- single port TNC. You would then treat /dev/ttyq0 and /dev/ttyq1 just
- as you would a conventional serial device with TNC connected. This
- means you'd then use the kissattach command as described above, on
- each of those, in the example for AX.25 ports called port1 and port2.
- You shouldn't use kissattach on the actual serial device as the mkiss
- program uses it.
-
- The mkiss command has a number of optional arguments that you may wish
- to use. They are summarised as follows:
-
- -c enables the addition of a one byte checksum to each KISS frame.
- This is not supported by most KISS implementation, it is
- supported by the G8BPG KISS rom.
-
- -s <speed>
- sets the speed of the serial port.
-
- -h enables hardware handshaking on the serial port, it is off by
- default. Most KISS implementation do not support this, but some
- do.
-
- -l enables logging of information to the syslog logfile.
-
- 6.1.2. Creating a Baycom device.
-
- Kernel Compile Options:
-
- Code maturity level options --->
- [*] Prompt for development and/or incomplete code/drivers
- General setup --->
- [*] Networking support
- Network device support --->
- [*] Network device support
- ...
- [*] Radio network interfaces
- [*] BAYCOM ser12 and par96 driver for AX.25
-
- Thomas Sailer, <sailer@ife.ee.ethz.ch>, despite the popularly held
- belief that it would not work very well, has developed Linux support
- for Baycom modems. His driver supports the Ser12 serial port, Par96
- and the enhanced PicPar parallel port modems. Further information
- about the modems themselves may be obtained from the Baycom Web site
- <http://www.baycom.de/>.
-
- Your first step should be to determine the i/o and addresses of the
- serial or parallel port(s) you have Baycom modem(s) connected to.
- When you have these you must configure the Baycom driver with them.
-
- The BayCom driver creates network devices called: bc0, bc1, bc2 etc.
- when it is configured.
-
- The sethdlc utility allows you to configure the driver with these
- parameters, or, if you have only one Baycom modem installed you may
- specify the parameters on the insmod commmand line when you load the
- Baycom module.
-
- For example, a simple configuration. Disable the serial driver for
- COM1: then configure the Baycom driver for a Ser12 serial port modem
- on COM1: with the software DCD option enabled:
-
- # setserial /dev/ttyS0 uart none
- # insmod hdlcdrv
- # insmod baycom mode="ser12*" iobase=0x3f8 irq=4
-
- Par96 parallel port type modem on LPT1: using hardware DCD detection:
-
- # insmod hdlcdrv
- # insmod baycom mode="par96" iobase=0x378 irq=7 options=0
-
- This is not really the preferred way to do it. The sethdlc utility
- works just as easily with one device as with many.
-
- The sethdlc man page has the full details, but a couple of examples
- will illustrate the most important aspects of this configuration. The
- following examples assume you have already loaded the Baycom module
- using:
-
- # insmod hdlcdrv
- # insmod baycom
-
- or that you compiled the kernel with the driver inbuilt.
-
- Configure the bc0 device driver as a Parallel port Baycom modem on
- LPT1: with software DCD:
-
- # sethdlc -p -i bc0 mode par96 io 0x378 irq 7
-
- Configure the bc1 device driver as a Serial port Baycom modem on COM1:
-
- # sethdlc -p -i bc1 mode "ser12*" io 0x3f8 irq 4
-
- 6.1.3. Configuring the AX.25 channel access parameters.
-
- The AX.25 channel access parameters are the equivalent of the KISS
- ppersist, txdelay and slottime type parameters. Again you use the
- sethdlc utility for this.
-
- Again the sethdlc man page is the source of the most complete
- information but another example of two won't hurt:
-
- Configure the bc0 device with TxDelay of 200 mS, SlotTime of 100 mS,
- PPersist of 40 and half duplex:
-
- # sethdlc -i bc0 -a txd 200 slot 100 ppersist 40 half
-
- Note that the timing values are in milliseconds.
-
- 6.1.3.1. Configuring the Kernel AX.25 to use the BayCom device
-
- The BayCom driver creates standard network devices that the AX.25
- Kernel code can use. Configuration is much the same as that for a PI
- or PacketTwin card.
-
- The first step is to configure the device with an AX.25 callsign. The
- ifconfig utility may be used to perform this.
-
- # /sbin/ifconfig bc0 hw ax25 VK2KTJ-15 up
-
- will assign the BayCom device bc0 the AX.25 callsign VK2KTJ-15.
- Alternatively you can use the axparms command, you'll still need to
- use the ifconfig command to bring the device up though:
-
- # ifconfig bc0 up
- # axparms -setcall bc0 vk2ktj-15
-
- The next step is to create an entry in the /etc/ax25/axports file as
- you would for any other device. The entry in the axports file is
- associated with the network device you've configured by the callsign
- you configure. The entry in the axports file that has the callsign
- that you configured the BayCom device with is the one that will be
- used to refer to it.
-
- You may then treat the new AX.25 device as you would any other. You
- can configure it for TCP/IP, add it to ax25d and run NetRom or Rose
- over it as you please.
-
- 6.1.4. Creating a SoundModem device.
-
- Kernel Compile Options:
-
- Code maturity level options --->
- [*] Prompt for development and/or incomplete code/drivers
- General setup --->
- [*] Networking support
- Network device support --->
- [*] Network device support
- ...
- [*] Radio network interfaces
- [*] Soundcard modem driver for AX.25
- [?] Soundmodem support for Soundblaster and compatible cards
- [?] Soundmodem support for WSS and Crystal cards
- [?] Soundmodem support for 1200 baud AFSK modulation
- [?] Soundmodem support for 4800 baud HAPN-1 modulation
- [?] Soundmodem support for 9600 baud FSK G3RUH modulation
-
- Thomas Sailer has built a new driver for the kernel that allows you to
- use your soundcard as a modem. Connect your radio directly to your
- soundcard to play packet! Thomas recommends at least a 486DX2/66 if
- you want to use this software as all of the digital signal processing
- is done by the main CPU.
-
- The driver currently emulates 1200 bps AFSK, 4800 HAPN and 9600 FSK
- (G3RUH compatible) modem types. The only sound cards currently
- supported are SoundBlaster and WindowsSoundSystem Compatible models.
- The sound cards require some circuitry to help them drive the Push-To-
- Talk circuitry, and information on this is available from Thomas's
- SoundModem PTT circuit web page
- <http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html>. There are
- quite a few possible options, they are: detect the sound output from
- the soundcard, or use output from a parallel port, serial port or midi
- port. Circuit examples for each of these are on Thomas's site.
-
- The SoundModem driver creates network devices called: sm0, sm1, sm2
- etc when it is configured.
-
- Note: the SoundModem driver competes for the same resources as the
- Linux sound driver. So if you wish to use the SoundModem driver you
- must ensure that the Linux sound driver is not installed. You can of
- course compile them both as modules and insert and remove them as you
- wish.
-
- 6.1.4.1. Configuring the sound card.
-
- The SoundModem driver does not initialise the sound card. The
- ax25-utils package includes a utility to do this called `setcrystal'
- that may be used for SoundCards based on the Crystal chipset. If you
- have some other card then you will have to use some other software to
- initialise it. Its syntax is fairly straightforward:
-
- setcrystal [-w wssio] [-s sbio] [-f synthio] [-i irq] [-d dma] [-c dma2]
-
- So, for example, if you wished to configure a soundblaster card at i/o
- base address 0x388, irq 10 and DMA 1 you would use:
- # setcrystal -s 0x388 -i 10 -d 1
-
- To configure a WindowSoundSystem card at i/o base address 0x534, irq
- 5, DMA 3 you would use:
-
- # setcrystal -w 0x534 -i 5 -d 3
-
- The [-f synthio] parameter is the set the synthesiser address, and the
- [-c dma2] parameter is to set the second DMA channel to allow full
- duplex operation.
-
- 6.1.4.2. Configuring the SoundModem driver.
-
- When you have configured the soundcard you need to configure the
- driver telling it where the sound card is located and what sort of
- modem you wish it to emulate.
-
- The sethdlc utility allows you to configure the driver with these
- parameters, or, if you have only one soundcard installed you may
- specify the parameters on the insmod commmand line when you load the
- SoundModem module.
-
- For example, a simple configuration, with one SoundBlaster soundcard
- configured as described above emulating a 1200 bps modem:
-
- # insmod hdlcdrv
- # insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1
-
- This is not really the preferred way to do it. The sethdlc utility
- works just as easily with one device as with many.
-
- The sethdlc man page has the full details, but a couple of examples
- will illustrate the most important aspects of this configuration. The
- following examples assume you have already loaded the SoundModem
- modules using:
-
- # insmod hdlcdrv
- # insmod soundmodem
-
- or that you compiled the kernel with the driver inbuilt.
-
- Configure the driver to support the WindowsSoundSystem card we
- configured above to emulate a G3RUH 9600 compatible modem as device
- sm0 using a parallel port at 0x378 to key the Push-To-Talk:
-
- # sethdlc -p -i sm0 mode wss:fsk9600 io 0x534 irq 5 dma 3 pario 0x378
-
- Configure the driver to support the SoundBlaster card we configured
- above to emulate a 4800 bps HAPN modem as device sm1 using the serial
- port located at 0x2f8 to key the Push-To-Talk:
-
- # sethdlc -p -i sm1 mode sbc:hapn4800 io 0x388 irq 10 dma 1 serio 0x2f8
-
- Configure the driver to support the SoundBlaster card we configured
- above to emulate a 1200 bps AFSK modem as device sm1 using the serial
- port located at 0x2f8 to key the Push-To-Talk:
-
- # sethdlc -p -i sm1 mode sbc:afsk1200 io 0x388 irq 10 dma 1 serio 0x2f8
-
- 6.1.4.3. Configuring the AX.25 channel access parameters.
-
- The AX.25 channel access parameters are the equivalent of the KISS
- ppersist, txdelay and slottime type parameters. You use the sethdlc
- utility for this as well.
-
- Again the sethdlc man page is the source of the most complete
- information but another example of two won't hurt:
-
- Configure the sm0 device with TxDelay of 100 mS, SlotTime of 50mS,
- PPersist of 128 and full duplex:
-
- # sethdlc -i sm0 -a txd 100 slot 50 ppersist 128 full
-
- Note that the timing values are in milliseconds.
-
- 6.1.4.4. Setting the audio levels and tuning the driver.
-
- It is very important that the audio levels be set correctly for any
- radio based modem to work. This is equally true of the SoundModem.
- Thomas has developed some utility programs that make this task easier.
- They are called smdiag and smmixer.
-
- smdiag
- provides two types of display, either an oscilloscope type
- display or an eye pattern type display.
-
- smmixer
- allows you to actually adjust the transmit and receive audio
- levels.
-
- To start the smdiag utility in 'eye' mode for the SoundModem device
- sm0 you would use:
-
- # smdiag -i sm0 -e
-
- To start the smmixer utility for the SoundModem device sm0 you would
- use:
-
- # smmixer -i sm0
-
- 6.1.4.5. Configuring the Kernel AX.25 to use the SoundModem
-
- The SoundModem driver creates standard network devices that the AX.25
- Kernel code can use. Configuration is much the same as that for a PI
- or PacketTwin card.
-
- The first step is to configure the device with an AX.25 callsign. The
- ifconfig utility may be used to perform this.
-
- # /sbin/ifconfig sm0 hw ax25 VK2KTJ-15 up
-
- will assign the SoundModem device sm0 the AX.25 callsign VK2KTJ-15.
- Alternatively you can use the axparms command, but you still need the
- ifconfig utility to bring the device up:
-
- # ifconfig sm0 up
- # axparms -setcall sm0 vk2ktj-15
-
- The next step is to create an entry in the /etc/ax25/axports file as
- you would for any other device. The entry in the axports file is
- associated with the network device you've configured by the callsign
- you configure. The entry in the axports file that has the callsign
- that you configured the SoundModem device with is the one that will be
- used to refer to it.
-
- You may then treat the new AX.25 device as you would any other. You
- can configure it for TCP/IP, add it to ax25d and run NetRom or Rose
- over it as you please.
-
- 6.1.5. Creating a PI card device.
-
- Kernel Compile Options:
-
- General setup --->
- [*] Networking support
- Network device support --->
- [*] Network device support
- ...
- [*] Radio network interfaces
- [*] Ottawa PI and PI/2 support for AX.25
-
- The PI card device driver creates devices named `pi[0-9][ab]'. The
- first PI card detected will be allocated `pi0', the second `pi1' etc.
- The `a' and `b' refer to the first and second physical interface on
- the PI card. If you have built your kernel to include the PI card
- driver, and the card has been properly detected then you can use the
- following command to configure the network device:
-
- # /sbin/ifconfig pi0a hw ax25 VK2KTJ-15 up
-
- This command would configure the first port on the first PI card
- detected with the callsign VK2KTJ-15 and make it active. To use the
- device all you now need to do is to configure an entry into your
- /etc/ax25/axports file with a matching callsign/ssid and you will be
- ready to continue on.
-
- The PI card driver was written by David Perry, <dp@hydra.carleton.edu>
-
- 6.1.6. Creating a PacketTwin device.
-
- Kernel Compile Options:
-
- General setup --->
- [*] Networking support
- Network device support --->
- [*] Network device support
- ...
- [*] Radio network interfaces
- [*] Gracilis PackeTwin support for AX.25
-
- The PacketTwin card device driver creates devices named `pt[0-9][ab]'.
- The first PacketTwin card detected will be allocated `pt0', the second
- `pt1' etc. The `a' and `b' refer to the first and second physical
- interface on the PacketTwin card. If you have built your kernel to
- include the PacketTwin card driver, and the card has been properly
- detected then you can use the following command to configure the
- network device:
-
- # /sbin/ifconfig pt0a hw ax25 VK2KTJ-15 up
-
- This command would configure the first port on the first PacketTwin
- card detected with the callsign VK2KTJ-15 and make it active. To use
- the device all you now need to do is to configure an entry into your
- /etc/ax25/axports file with a matching callsign/ssid and you will be
- ready to continue on.
-
- The PacketTwin card driver was written by Craig Small VK2XLZ,
- <csmall@triode.apana.org.au>.
-
- 6.1.7. Creating a generic SCC device.
-
- Kernel Compile Options:
-
- General setup --->
- [*] Networking support
- Network device support --->
- [*] Network device support
- ...
- [*] Radio network interfaces
- [*] Z8530 SCC KISS emulation driver for AX.25
-
- Joerg Reuter, DL1BKE, jreuter@poboxes.com has developed generic
- support for Z8530 SCC based cards. His driver is configurable to
- support a range of different types of cards and present an interface
- that looks like a KISS TNC so you can treat it as though it were a
- KISS TNC.
-
- 6.1.7.1. Obtaining and building the configuration tool package.
-
- While the kernel driver is included in the standard kernel
- distribution, Joerg distributes more recent versions of his driver
- with the suite of configuration tools that you will need to obtain as
- well.
-
- You can obtain the configuration tools package from:
-
- Joerg's web page <http://www.rat.de/jr/>
-
- or:
-
- db0bm.automation.fh-aachen.de
-
- /incoming/dl1bke/
-
- or:
-
- insl1.etec.uni-karlsruhe.de
-
- /pub/hamradio/linux/z8530/
-
- or:
-
- ftp.ucsd.edu
-
- /hamradio/packet/tcpip/linux
- /hamradio/packet/tcpip/incoming/
-
- You will find multiple versions, choose the one that best suits the
- kernel you intend to use:
-
- z8530drv-2.4a.dl1bke.tar.gz 2.0.*
- z8530drv-utils-3.0.tar.gz 2.1.6 or greater
-
- The following commands were what I used to compile and install the
- package for kernel version 2.0.30:
-
- # cd /usr/src
- # gzip -dc z8530drv-2.4a.dl1bke.tar.gz | tar xvpofz -
- # cd z8530drv
- # make clean
- # make dep
- # make module # If you want to build the driver as a module
- # make for_kernel # If you want the driver to built into your kernel
- # make install
-
- After the above is complete you should have three new programs
- installed in your /sbin directory: gencfg, sccinit and sccstat. It is
- these programs that you will use to configure the driver for your
- card.
-
- You will also have a group of new special device files created in your
- /dev called scc0-scc7. These will be used later and will be the `KISS'
- devices you will end up using.
-
- If you chose to 'make for_kernel' then you will need to recompile your
- kernel. To ensure that you include support for the z8530 driver you
- must be sure to answer `Y' to: `Z8530 SCC kiss emulation driver for
- AX.25' when asked during a kernel `make config'.
-
- If you chose to 'make module' then the new scc.o will have been
- installed in the appropriate /lib/modules directory and you do not
- need to recompile your kernel. Remember to use the insmod command to
- load the module before your try and configure it.
-
- 6.1.7.2. Configuring the driver for your card.
-
- The z8530 SCC driver has been designed to be as flexible as possible
- so as to support as many different types of cards as possible. With
- this flexibility has come some cost in configuration.
-
- There is more comprehensive documentation in the package and you
- should read this if you have any problems. You should particularly
- look at doc/scc_eng.doc or doc/scc_ger.doc for more detailed
- information. I've paraphrased the important details, but as a result
- there is a lot of lower level detail that I have not included.
-
- The main configuration file is read by the sccinit program and is
- called /etc/z8530drv.conf. This file is broken into two main stages:
- Configuration of the hardware parameters and channel configuration.
- After you have configured this file you need only add:
-
- # sccinit
-
- into the rc file that configures your network and the driver will be
- initialised according to the contents of the configuration file. You
- must do this before you attempt to use the driver.
-
- 6.1.7.2.1. Configuration of the hardware parameters.
-
- The first section is broken into stanzas, each stanza representing an
- 8530 chip. Each stanza is a list of keywords with arguments. You may
- specify up to four SCC chips in this file by default. The #define
- MAXSCC 4 in scc.c can be increased if you require support for more.
-
- The allowable keywords and arguments are:
-
- chip
- the chip keyword is used to separate stanzas. It will take
- anything as an argument. The arguments are not used.
-
- data_a
- this keyword is used to specify the address of the data port for
- the z8530 channel `A'. The argument is a hexadecimal number e.g.
- 0x300
-
- ctrl_a
- this keyword is used to specify the address of the control port
- for the z8530 channel `A'. The arguments is a hexadecimal number
- e.g. 0x304
-
- data_b
- this keyword is used to specify the address of the data port for
- the z8530 channel `B'. The argument is a hexadecimal number e.g.
- 0x301
-
- ctrl_b
- this keyword is used to specify the address of the control port
- for the z8530 channel `B'. The arguments is a hexadecimal number
- e.g. 0x305
-
- irq
- this keyword is used to specify the IRQ used by the 8530 SCC
- described in this stanza. The argument is an integer e.g. 5
-
- pclock
- this keyword is used to specify the frequency of the clock at
- the PCLK pin of the 8530. The argument is an integer frequency
- in Hz which defaults to 4915200 if the keyword is not supplied.
-
- board
- the type of board supporting this 8530 SCC. The argument is a
- character string. The allowed values are:
-
- PA0HZP
- the PA0HZP SCC Card
-
- EAGLE
- the Eagle card
-
- PC100
- the DRSI PC100 SCC card
- PRIMUS
- the PRIMUS-PC (DG9BL) card
-
- BAYCOM
- BayCom (U)SCC card
-
- escc
- this keyword is optional and is used to enable support for the
- Extended SCC chips (ESCC) such as the 8580, 85180, or the 85280.
- The argument is a character string with allowed values of `yes'
- or `no'. The default is `no'.
-
- vector
- this keyword is optional and specifies the address of the vector
- latch (also known as "intack port") for PA0HZP cards. There can
- be only one vector latch for all chips. The default is 0.
-
- special
- this keyword is optional and specifies the address of the
- special function register on several cards. The default is 0.
-
- option
- this keyword is optional and defaults to 0.
-
- Some example configurations for the more popular cards are as follows:
-
- BayCom USCC
-
- chip 1
- data_a 0x300
- ctrl_a 0x304
- data_b 0x301
- ctrl_b 0x305
- irq 5
- board BAYCOM
- #
- # SCC chip 2
- #
- chip 2
- data_a 0x302
- ctrl_a 0x306
- data_b 0x303
- ctrl_b 0x307
- board BAYCOM
-
- PA0HZP SCC card
-
- chip 1
- data_a 0x153
- data_b 0x151
- ctrl_a 0x152
- ctrl_b 0x150
- irq 9
- pclock 4915200
- board PA0HZP
- vector 0x168
- escc no
- #
- #
- #
- chip 2
- data_a 0x157
- data_b 0x155
- ctrl_a 0x156
- ctrl_b 0x154
- irq 9
- pclock 4915200
- board PA0HZP
- vector 0x168
- escc no
-
- DRSI SCC card
-
- chip 1
- data_a 0x303
- data_b 0x301
- ctrl_a 0x302
- ctrl_b 0x300
- irq 7
- pclock 4915200
- board DRSI
- escc no
-
- If you already have a working configuration for your card under NOS,
- then you can use the gencfg command to convert the PE1CHL NOS driver
- commands into a form suitable for use in the z8530 driver
- configuration file.
-
- To use gencfg you simply invoke it with the same parameters as you
- used for the PE1CHL driver in NET/NOS. For example:
-
- # gencfg 2 0x150 4 2 0 1 0x168 9 4915200
-
- will generate a skeleton configuration for the OptoSCC card.
-
- 6.1.7.3. Channel Configuration
-
- The Channel Configuration section is where you specify all of the
- other parameters associated with the port you are configuring. Again
- this section is broken into stanzas. One stanza represents one logical
- port, and therefore there would be two of these for each one of the
- hardware parameters stanzas as each 8530 SCC supports two ports.
-
- These keywords and arguments are also written to the
- /etc/z8530drv.conf file and must appear after the hardware parameters
- section.
-
- Sequence is very important in this section, but if you stick with the
- suggested sequence it should work ok. The keywords and arguments are:
-
- device
- this keyword must be the first line of a port definition and
- specifies the name of the special device file that the rest of
- the configuration applies to. e.g. /dev/scc0
-
- speed
- this keyword specifies the speed in bits per second of the
- interface. The argument is an integer: e.g. 1200
-
- clock
- this keyword specifies where the clock for the data will be
- sourced. Allowable values are:
-
- dpll
- normal halfduplex operation
-
- external
- MODEM supplies its own Rx/Tx clock
-
- divider
- use fullduplex divider if installed.
-
- mode
- this keyword specifies the data coding to be used. Allowable
- arguments are: nrzi or nrz
-
- rxbuffers
- this keyword specifies the number of receive buffers to allocate
- memory for. The argument is an integer, e.g. 8.
-
- txbuffers
- this keyword specifies the number of transmit buffers to
- allocate memory for. The argument is an integer, e.g. 8.
-
- bufsize
- this keyword specifies the size of the receive and transmit
- buffers. The arguments is in bytes and represents the total
- length of the frame, so it must also take into account the AX.25
- headers and not just the length of the data field. This keyword
- is optional and default to 384
-
- txdelay
- the KISS transmit delay value, the argument is an integer in mS.
-
- persist
- the KISS persist value, the argument is an integer.
-
- slot
- the KISS slot time value, the argument is an integer in mS.
-
- tail
- the KISS transmit tail value, the argument is an integer in mS.
-
- fulldup
- the KISS full duplex flag, the argument is an integer. 1==Full
- Duplex, 0==Half Duplex.
-
- wait
- the KISS wait value, the argument is an integer in mS.
-
- min
- the KISS min value, the argument is an integer in S.
-
- maxkey
- the KISS maximum keyup time, the argument is an integer in S.
-
- idle
- the KISS idle timer value, the argument is an integer in S.
-
- maxdef
- the KISS maxdef value, the argument is an integer.
-
- group
- the KISS group value, the argument is an integer.
-
- txoff
- the KISS txoff value, the argument is an integer in mS.
-
- softdcd
- the KISS softdcd value, the argument is an integer.
-
- slip
- the KISS slip flag, the argument is an integer.
-
- 6.1.7.4. Using the driver.
-
- To use the driver you simply treat the /dev/scc* devices just as you
- would a serial tty device with a KISS TNC connected to it. For
- example, to configure Linux Kernel networking to use your SCC card you
- could use something like:
-
- # kissattach -s 4800 /dev/scc0 VK2KTJ
-
- You can also use NOS to attach to it in precisely the same way. From
- JNOS for example you would use something like:
-
- attach asy scc0 0 ax25 scc0 256 256 4800
-
- 6.1.7.5. The sccstat and sccparam tools.
-
- To assist in the diagnosis of problems you can use the sccstat program
- to display the current configuration of an SCC device. To use it try:
-
- # sccstat /dev/scc0
-
- you will displayed a very large amount of information relating to the
- configuration and health of the /dev/scc0 SCC port.
- The sccparam command allows you to change or modify a configuration
- after you have booted. Its syntax is very similar to the NOS param
- command, so to set the txtail setting of a device to 100mS you would
- use:
-
- # sccparam /dev/scc0 txtail 0x8
-
- 6.1.8. Creating a BPQ ethernet device.
-
- Kernel Compile Options:
-
- General setup --->
- [*] Networking support
- Network device support --->
- [*] Network device support
- ...
- [*] Radio network interfaces
- [*] BPQ Ethernet driver for AX.25
-
- Linux supports BPQ Ethernet compatibility. This enables you to run the
- AX.25 protocol over your Ethernet LAN and to interwork your linux
- machine with other BPQ machines on the LAN.
-
- The BPQ network devices are named `bpq[0-9]'. The `bpq0' device is
- associated with the `eth0' device, the `bpq1' device with the `eth1'
- device etc.
-
- Configuration is quite straightforward. You firstly must have
- configured a standard Ethernet device. This means you will have
- compiled your kernel to support your Ethernet card and tested that
- this works. Refer to the Ethernet-HOWTO <Ethernet-HOWTO.html> for more
- information on how to do this.
-
- To configure the BPQ support you need to configure the Ethernet device
- with an AX.25 callsign. The following command will do this for you:
-
- # /sbin/ifconfig bpq0 hw ax25 vk2ktj-14 up
-
- Again, remember that the callsign you specify should match the entry
- in the /etc/ax25/axports file that you wish to use for this port.
-
- 6.1.9. Configuring the BPQ Node to talk to the Linux AX.25 support.
-
- BPQ Ethernet normally uses a multicast address. The Linux
- implementation does not, and instead it uses the normal Ethernet
- broadcast address. The NET.CFG file for the BPQ ODI driver should
- therefore be modifified to look similar to this:
-
- LINK SUPPORT
-
- MAX STACKS 1
- MAX BOARDS 1
-
- LINK DRIVER E2000 ; or other MLID to suit your card
-
- INT 10 ;
- PORT 300 ; to suit your card
-
- FRAME ETHERNET_II
-
- PROTOCOL BPQ 8FF ETHERNET_II ; required for BPQ - can change PID
-
- BPQPARAMS ; optional - only needed if you want
- ; to override the default target addr
-
- ETH_ADDR FF:FF:FF:FF:FF:FF ; Target address
-
- 6.2. Creating the /etc/ax25/axports file.
-
- The /etc/ax25/axports is a simple text file that you create with a
- text editor. The format of the /etc/ax25/axports file is as follows:
-
- portname callsign baudrate paclen window description
-
- where:
-
- portname
- is a text name that you will refer to the port by.
-
- callsign
- is the AX.25 callsign you want to assign to the port.
-
- baudrate
- is the speed at which you wish the port to communicate with your
- TNC.
-
- paclen
- is the maximum packet length you want to configure the port to
- use for AX.25 connected mode connections.
-
- window
- is the AX.25 window (K) parameter. This is the same as the
- MAXFRAME setting of many tnc's.
-
- description
- is a textual description of the port.
-
- In my case, mine looks like:
-
- radio VK2KTJ-15 4800 256 2 4800bps 144.800 MHz
- ether VK2KTJ-14 10000000 256 2 BPQ/ethernet device
-
- Remember, you must assign unique callsign/ssid to each AX.25 port you
- create. Create one entry for each AX.25 device you want to use, this
- includes KISS, Baycom, SCC, PI, PT and SoundModem ports. Each entry
- here will describe exactly one AX.25 network device. The entries in
- this file are associated with the network devices by the
- callsign/ssid. This is at least one good reason for requiring unique
- callsign/ssid.
-
- 6.3. Configuring AX.25 routing.
-
- You may wish to configure default digipeaters paths for specific
- hosts. This is useful for both normal AX.25 connections and also IP
- based connections. The axparms command enables you to do this. Again,
- the man page offers a complete description, but a simple example might
- be:
-
- # /usr/sbin/axparms -route add radio VK2XLZ VK2SUT
-
- This command would set a digipeater entry for VK2XLZ via VK2SUT on the
- AX.25 port named radio.
-
- 7. Configuring an AX.25 interface for TCP/IP.
-
- It is very simple to configure an AX.25 port to carry TCP/IP. If you
- have KISS interfaces then there are two methods for configuring an IP
- address. The kissattach command has an option that allows you to do
- specify an IP address. The more conventional method using the ifconfig
- command will work on all interface types.
-
- So, modifying the previous KISS example:
-
- # /usr/sbin/kissattach -i 44.136.8.5 -m 512 /dev/ttyS0 radio
- # /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 ax0
- # /sbin/route add default ax0
-
- to create the AX.25 interface with an IP address of 44.136.8.5 and an
- MTU of 512 bytes. You should still use the ifconfig to configure the
- other parameters if necessary.
-
- If you have any other interface type then you use the ifconfig program
- to configure the ip address and netmask details for the port and add a
- route via the port, just as you would for any other TCP/IP interface.
- The following example is for a PI card device, but would work equally
- well for any other AX.25 network device:
-
- # /sbin/ifconfig pi0a 44.136.8.5 netmask 255.255.255.0 up
- # /sbin/ifconfig pi0a broadcast 44.136.8.255 mtu 512
- # /sbin/route add -net 44.136.8.0 netmask 255.255.255.0 pi0a
- # /sbin/route add default pi0a
-
- The commands listed above are typical of the sort of configuration
- many of you would be familiar with if you have used NOS or any of its
- derivatives or any other TCP/IP software. Note that the default route
- might not be required in your configuration if you have some other
- network device configured.
-
- To test it out, try a ping or a telnet to a local host.
-
- # ping -i 5 44.136.8.58
-
- Note the use of the `-i 5' arguments to ping to tell it to send pings
- every 5 seconds instead of its default of 1 second.
-
- 8. Configuring a NetRom port.
-
- The NetRom protocol relies on, and uses the AX.25 ports you have
- created. The NetRom protocol rides on top of the AX.25 protocol. To
- configure NetRom on an AX.25 interface you must configure two files.
- One file describes the Netrom interfaces, and the other file describes
- which of the AX.25 ports will carry NetRom. You can configure multiple
- NetRom ports, each with its own callsign and alias, the same procedure
- applies for each.
-
- 8.1. Configuring /etc/ax25/nrports
-
- The first is the /etc/ax25/nrports file. This file describes the
- NetRom ports in much the same way as the /etc/ax25/axports file
- describes the AX.25 ports. Each NetRom device you wish to create must
- have an entry in the /etc/ax25/nrports file. Normally a Linux machine
- would have only one NetRom device configured that would use a number
- of the AX.25 ports defined. In some situations you might wish a
- special service such as a BBS to have a seperate NetRom alias and so
- you would create more than one.
-
- This file is formatted as follows:
-
- name callsign alias paclen description
-
- Where:
-
- name
- is the text name that you wish to refer to the port by.
-
- callsign
- is the callsign that the NetRom traffic from this port will use.
- Note, this is not that address that users should connect to to
- get access to a node style interface. (The node program is
- covered later). This callsign/ssid should be unique and should
- not appear elsewhere in either of the /etc/ax25/axports or the
- /etc/ax25/nrports files.
-
- alias
- is the NetRom alias this port will have assigned to it.
-
- paclen
- is the maximum size of NetRom frames transmitted by this port.
-
- description
- is a free text description of the port.
-
- An example would look something like the following:
-
- netrom VK2KTJ-9 LINUX 236 Linux Switch Port
-
- This example creates a NetRom port known to the rest of the NetRom
- network as `LINUX:VK2KTJ-9'.
-
- This file is used by programs such as the call program.
-
- 8.2. Configuring /etc/ax25/nrbroadcast
-
- The second file is the /etc/ax25/nrbroadcast file. This file may
- contain a number of entries. There would normally be one entry for
- each AX.25 port that you wish to allow NetRom traffic on.
-
- This file is formatted as follows:
-
- axport min_obs def_qual worst_qual verbose
-
- Where:
-
- axport
- is the port name obtained from the /etc/ax25/axports file. If
- you do not have an entry in /etc/ax25/nrbroadcasts for a port
- then this means that no NetRom routing will occur and any
- received NetRom broadcasts will be ignored for that port.
-
- min_obs
- is the minimum obselesence value for the port.
-
- def_qual
- is the default quality for the port.
-
- worst_qual
- is the worst quality value for the port, any routes under this
- quality will be ignored.
-
- verbose
- is a flag determining whether full NetRom routing broadcasts
- will occur from this port or only a routing broadcast
- advertising the node itself.
-
- An example would look something like the following:
-
- radio 1 200 100 1
-
- 8.3. Creating the NetRom Network device
-
- When you have the two configuration files completed you must create
- the NetRom device in much the same way as you did for the AX.25
- devices. This time you use the nrattach command. The nrattach works
- in just the same way as the axattach command except that it creates
- NetRom network devices called `nr[0-9]'. Again, the first time you use
- the nrattach command it creates the `nr0' device, the second time it
- creates the `nr1' network devices etc. To create the network device
- for the NetRom port we've defined we would use:
-
- # nrattach netrom
-
- This command would start the NetRom device (nr0) named netrom
- configured with the details specified in the /etc/ax25/nrports file.
-
- 8.4. Starting the NetRom daemon
-
- The Linux kernel does all of the NetRom protocol and switching, but
- does not manage some functions. The NetRom daemon manages the NetRom
- routing tables and generates the NetRom routing broadcasts. You start
- NetRom daemon with the command:
-
- # /usr/sbin/netromd -i
-
- You should soon see the /proc/net/nr_neigh file filling up with
- information about your NetRom neighbours.
-
- Remember to put the /usr/sbin/netromd command in your rc files so that
- it is started automatically each time you reboot.
-
- 8.5. Configuring NetRom routing.
-
- You may wish to configure static NetRom routes for specific hosts.
- The nrparms command enables you to do this. Again, the man page offers
- a complete description, but a simple example might be:
-
- # /usr/sbin/nrparms -nodes VK2XLZ-10 + #MINTO 120 5 radio VK2SUT-9
-
- This command would set a NetRom route to #MINTO:VK2XLZ-10 via a
- neighbour VK2SUT-9 on my AX.25 port called `radio'.
-
- You can manually create entries for new neighbours using the nrparms
- command as well. For example:
-
- # /usr/sbin/nrparms -routes radio VK2SUT-9 + 120
-
- This command would create VK2SUT-9 as a NetRom neighbour with a
- quality of 120 and this will be locked and will not be deleted
- automatically.
-
- 9. Configuring a NetRom interface for TCP/IP.
-
- Configuring a NetRom interface for TCP/IP is almost identical to
- configuring an AX.25 interface for TCP/IP.
-
- Again you can either specify the ip address and mtu on the nrattach
- command line, or use the ifconfig and route commands, but you need to
- manually add arp entries for hosts you wish to route to because there
- is no mechanism available for your machine to learn what NetRom
- address it should use to reach a particular IP host.
-
- So, to create an nr0 device with an IP address of 44.136.8.5, an mtu
- of 512 and configured with the details from the /etc/ax25/nrports file
- for a NetRom port named netrom you would use:
-
- # /usr/sbin/nrattach -i 44.136.8.5 -m 512 netrom
- # route add 44.136.8.5 nr0
-
- or you could use something like the following commands manually:
-
- # /usr/sbin/nrattach netrom
- # ifconfig nr0 44.136.8.5 netmask 255.255.255.0 hw netrom VK2KTJ-9
- # route add 44.136.8.5 nr0
-
- Then for each IP host you wish to reach via NetRom you need to set
- route and arp entries. To reach a destination host with an IP address
- of 44.136.80.4 at NetRom address BBS:VK3BBS via a NetRom neighbour
- with callsign VK2SUT-0 you would use commands as follows:
-
- # route add 44.136.80.4 nr0
- # arp -t netrom -s 44.136.80.4 vk2sut-0
- # nrparms -nodes vk3bbs + BBS 120 6 sl0 vk2sut-0
-
- The `120' and `6' arguments to the nrparms command are the NetRom
- quality and obsolescence count values for the route.
-
- 10. Configuring a Rose port.
-
- The Rose packet layer protocol is similar to layer three of the X.25
- specification. The kernel based Rose support is a modified version of
- the FPAC Rose implementation
- <http://fpac.lmi.ecp.fr/f1oat/f1oat.html>.
-
- The Rose packet layer protocol protocol relies on, and uses the AX.25
- ports you have created. The Rose protocol rides on top of the AX.25
- protocol. To configure Rose you must create a configuration file that
- describes the Rose ports you want. You can create multiple Rose ports
- if you wish, the same procedure applies for each.
-
- 10.1. Configuring /etc/ax25/rsports
-
- The file where you configure your Rose interfaces is the
- /etc/ax25/rsports file. This file describes the Rose port in much the
- same way as the /etc/ax25/axports file describes the AX.25 ports.
-
- This file is formatted as follows:
-
- name addresss description
-
- Where:
-
- name
- is the text name that you wish to refer to the port by.
-
- address
- is the 10 digit Rose address you wish to assign to this port.
-
- description
- is a free text description of the port.
-
- An example would look something like the following:
-
- rose 5050294760 Rose Port
-
- Note that Rose will use the default callsign/ssid configured on each
- AX.25 port unless you specify otherwise.
-
- To configure a seperate callsign/ssid for Rose to use on each port you
- use the rsparms command as follows:
-
- # /usr/sbin/rsprams -call VK2KTJ-10
-
- This example would make Linux listen for and use the callsign/ssid
- VK2KTJ-10 on all of the configured AX.25 ports for Rose calls.
-
- 10.2. Creating the Rose Network device.
-
- When you have created the /etc/ax25/rsports file you may create the
- Rose device in much the same way as you did for the AX.25 devices.
- This time you use the rsattach command. The rsattach command creates
- network devices named `rose[0-5]'. The first time you use the rsattach
- command it create the `rose0' device, the second time it creates the
- `rose1' device etc. For example:
-
- # rsattach rose
-
- This command would start the Rose device (rose0) configured with the
- details specified in the /etc/ax25/rsports file for the entry named
- `rose'.
-
- 10.3. Configuring Rose Routing
-
- The Rose protocol currently supports only static routing. The rsparms
- utility allows you to configure your Rose routing table under Linux.
-
- For example:
-
- # rsparms -nodes add 5050295502 radio vk2xlz
-
- would add a route to Rose node 5050295502 via an AX.25 port named
- `radio' in your /etc/ax25/axports file to a neighbour with the call¡
- sign VK2XLZ.
-
- You may specify a route with a mask to capture a number of Rose
- destinations into a single routing entry. The syntax looks like:
-
- # rsparms -nodes add 5050295502/4 radio vk2xlz
-
- which would be identical to the previous example except that it would
- match any destination address that matched the first four digits sup¡
- plied, in this case any address commencing with the digits 5050. An
- alternate form for this command is:
-
- # rsparms -nodes add 5050/4 radio vk2xlz
-
- which is probably the less ambiguous form.
-
- 11. Making AX.25/NetRom/Rose calls.
-
- Now that you have all of your AX.25, NetRom and Rose interfaces
- configured and active, you should be able to make test calls.
-
- The AX25 Utilities package includes a program called `call' which is a
- splitscreen terminal program for AX.25, NetRom and Rose.
-
- A simple AX.25 call would look like:
-
- /usr/bin/call radio VK2DAY via VK2SUT
-
- A simple NetRom call to a node with an alias of SUNBBS would look
- like:
-
- /usr/bin/call netrom SUNBBS
-
- A simple Rose call to HEARD at node 5050882960 would look like:
-
- /usr/bin/call rose HEARD 5050882960
-
- Note: you must tell call which port you wish to make the call on, as
- the same destination node might be reachable on any of the ports you
- have configured.
-
- The call program is a linemode terminal program for making AX.25
- calls. It recognises lines that start with `~' as command lines. The
- `~.' command will close the connection.
-
- Please refer to the man page in /usr/man for more information.
-
- 12. Configuring Linux to accept Packet connections.
-
- Linux is a powerful operating system and offers a great deal of
- flexibility in how it is configured. With this flexibility comes a
- cost in configuring it to do what you want. When configuring your
- Linux machine to accept incoming AX.25, NetRom or Rose connections
- there are a number of questions you need to ask yourself. The most
- important of which is: "What do I want users to see when they
- connect?". People are developing neat little applications that may be
- used to provide services to callers, a simple example is the pms
- program included in the AX25 utilities, a more complex example is the
- node program also included in the AX25 utilities. Alternatively you
- might want to give users a login prompt so that they can make use of a
- shell account, or you might even have written your own program, such
- as a customised database or a game, that you want people to connect
- to. Whatever you choose, you must tell the AX.25 software about this
- so that it knows what software to run when it accepts an incoming
- AX.25 connection.
-
- The ax25d program is similar to the inetd program commonly used to
- accept incoming TCP/IP connections on unix machines. It sits and
- listens for incoming connections, when it detects one it goes away and
- checks a configuration file to determine what program to run and
- connect to that connection. Since this the standard tool for accepting
- incoming AX.25, NetRom and Rose connections I'll describe how to
- configure it.
-
- 12.1. Creating the /etc/ax25/ax25d.conf file.
-
- This file is the configuration file for the ax25d AX.25 daemon which
- handles incoming AX.25, NetRom and Rose connections.
-
- The file is a little cryptic looking at first, but you'll soon
- discover it is very simple in practice, with a small trap for you to
- be wary of.
-
- The general format of the ax25d.conf file is as follows:
-
- # This is a comment and is ignored by the ax25d program.
- [port_name] || <port_name> || {port_name}
- <peer1> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
- <peer2> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
- parameters window T1 T2 T3 idle N2 <mode>
- <peer3> window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
- ...
- default window T1 T2 T3 idle N2 <mode> <uid> <cmd> <cmd-name> <arguments>
-
- Where:
-
- # at the start of a line marks a comment and is completely ignored
- by the ax25d program.
-
- <port_name>
- is the name of the AX.25, NetRom or Rose port as specified in
- the /etc/ax25/axports, /etc/ax25/nrports and /etc/ax25/rsports
- files. The name of the port is surrounded by the `[]' brackets
- if it is an AX.25 port, the `<>' brackets if it is a NetRom
- port, or the `{}' brackets if it is a Rose port. There is an
- alternate form for this field, and that is use prefix the port
- name with `callsign/ssid via' to indicate that you wish accept
- calls to the callsign/ssid via this interface. The example
- should more clearly illustrate this.
-
- <peer>
- is the callsign of the peer node that this particular
- configuration applies to. If you don't specify an SSID here then
- any SSID will match.
-
- window
- is the AX.25 Window parameter (K) or MAXFRAME parameter for this
- configuration.
-
- T1 is the Frame retransmission (T1) timer in half second units.
-
- T2 is the amount of time the AX.25 software will wait for another
- incoming frame before preparing a response in 1 second units.
-
- T3 is the amount of time of inactivity before the AX.25 software
- will disconnect the session in 1 second units.
-
- idle
- is the idle timer value in seconds.
-
- N2 is the number of consecutive retransmissions that will occur
- before the connection is closed.
-
- <mode>
- provides a mechanism for determining certain types of general
- permissions. The modes are enabled or disabled by supplying a
- combination of characters, each representing a permission. The
- characters may be in either upper or lower case and must be in a
- single block with no spaces.
-
- u/U
- UTMP - currently unsupported.
-
- v/V
- Validate call - currently unsupported.
-
- q/Q
- Quiet - Don't log connection
-
- n/N
- check NetRom Neighbour - currently unsupported.
-
- d/D
- Disallow Digipeaters - Connections must be direct, not
- digipeated.
-
- l/L
- Lockout - Don't allow connection.
-
- */0
- marker - place marker, no mode set.
-
- <uid>
- is the userid that the program to be run to support the
- connection should be run as.
-
- <cmd>
- is the full pathname of the command to be run, with no arguments
- specified.
-
- <cmd-name>
- is the text that should appear in a ps as the command name
- running (normally the same as <cmd> except without the directory
- path information.
-
- <arguments>
- are the command line argument to be passed to the <:cmd> when it
- is run. You pass useful information into these arguments by use
- of the following tokens:
-
- %d Name of the port the connection was received on.
-
- %U AX.25 callsign of the connected party without the SSID, in
- uppercase.
-
- %u AX.25 callsign of the connected party without the SSID, in
- lowercase.
-
- %S AX.25 callsign of the connected party with the SSID, in
- uppercase.
-
- %s AX.25 callsign of the connected party with the SSID, in
- lowercase.
-
- %P AX.25 callsign of the remote node that the connection came in
- from without the SSID, in uppercase.
-
- %p AX.25 callsign of the remote node that the connection came in
- from without the SSID, in lowercase.
-
- %R AX.25 callsign of the remote node that the connection came in
- from with the SSID, in uppercase.
-
- %r AX.25 callsign of the remote node that the connection came in
- from with the SSID, in lowercase.
-
- You need one section in the above format for each AX.25, NetRom or
- Rose interface you want to accept incoming AX.25, NetRom or Rose
- connections on.
-
- There are two special lines in the paragraph, one starts with the
- string `parameters' and the other starts with the string `default'
- (yes there is a difference). These lines serve special functions.
-
- The `default' lines purpose should be obvious, this line acts as a
- catch-all, so that any incoming connection on the <interface_call>
- interface that doesn't have a specific rule will match the `default'
- rule. If you don't have a `default' rule, then any connections not
- matching any specific rule will be disconnected immediately without
- notice.
-
- The `parameters' line is a little more subtle, and here is the trap I
- mentioned earlier. In any of the fields for any definition for a peer
- you can use the `*' character to say `use the default value'. The
- `parameters' line is what sets those default values. The kernel
- software itself has some defaults which will be used if you don't
- specify any using the `parameters' entry. The trap is that the these
- defaults apply only to those rules below the `parameters' line, not to
- those above. You may have more than one `parameters' rule per
- interface definition, and in this way you may create groups of default
- configurations. It is important to note that the `parameters' rule
- does not allow you to set the `uid' or `command' fields.
-
- 12.2. A simple example ax25d.conf file.
-
- Ok, an illustrative example:
-
- # ax25d.conf for VK2KTJ - 02/03/97
- # This configuration uses the AX.25 port defined earlier.
-
- # <peer> Win T1 T2 T3 idl N2 <mode> <uid> <exec> <argv[0]>[<args....>]
-
- [VK2KTJ-0 via radio]
- parameters 1 10 * * * * *
- VK2XLZ * * * * * * * root /usr/sbin/axspawn axspawn %u +
- VK2DAY * * * * * * * root /usr/sbin/axspawn axspawn %u +
- NOCALL * * * * * * L
- default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj
-
- [VK2KTJ-1 via radio]
- default * * * * * 0 root /usr/sbin/node node
-
- <netrom>
- parameters 1 10 * * * * *
- NOCALL * * * * * * L
- default * * * * * * 0 root /usr/sbin/node node
-
- {VK2KTJ-0 via rose}
- parameters 1 10 * * * * *
- VK2XLZ * * * * * * * root /usr/sbin/axspawn axspawn %u +
- VK2DAY * * * * * * * root /usr/sbin/axspawn axspawn %u +
- NOCALL * * * * * * L
- default 1 10 5 100 180 5 * root /usr/sbin/pms pms -a -o vk2ktj
-
- {VK2KTJ-1 via rose}
- default * * * * * 0 root /usr/sbin/node node radio
-
- This example says that anybody attempting to connect to the callsign
- `VK2KTJ-0' heard on the AX.25 port called `radio' will have the
- following rules applied:
-
- Anyone whose callsign is set to `NOCALL' should be locked out, note
- the use of mode `L'.
-
- The parameters line changes two parameters from the kernel defaults
- (Window and T1) and will run the /usr/sbin/axspawn program for them.
- Any copies of /usr/sbin/axspawn run this way will appear as axspawn in
- a ps listing for convenience. The next two lines provide definitions
- for two stations who will receive those permissions.
-
- The last line in the paragraph is the `catch all' definition that
- everybody else will get (including VK2XLZ and VK2DAY using any other
- SSID other than -1). This definition sets all of the parameters
- implicitly and will cause the pms program to be run with a command
- line argument indicating that it is being run for an AX.25 connection,
- and that the owner callsign is VK2KTJ. (See the `Configuring the PMS'
- section below for more details).
-
- The next configuration accepts calls to VK2KTJ-1 via the radio port.
- It runs the node program for everybody that connects to it.
-
- The next configuration is a NetRom configuration, note the use of the
- greater-then and less-than braces instead of the square brackets.
- These denote a NetRom configuration. This configuration is simpler, it
- simply says that anyone connecting to our NetRom port called `netrom'
- will have the node program run for them, unless they have a callsign
- of `NOCALL' in which case they will be locked out.
-
- The last two configurations are for incoming Rose connections. The
- first for people who have placed calls to `vk2ktj-0' and the second
- for `VK2KTJ-1 at the our Rose node address. These work precisely the
- same way. Not the use of the curly braces to distinguish the port as a
- Rose port.
-
- This example is a contrived one but I think it illustrates clearly the
- important features of the syntax of the configuration file. The
- configuration file is explained fully in the ax25d.conf man page. A
- more detailed example is included in the ax25-utils package that might
- be useful to you too.
-
- 12.3. Starting ax25d
-
- When you have the two configuration files completed you start ax25d
- with the command:
-
- # /usr/sbin/ax25d
-
- When this is run people should be able to make AX.25 connections to
- your Linux machine. Remember to put the ax25d command in your rc files
- so that it is started automatically when you reboot each time.
-
- 13. Configuring the node software.
-
- The node software was developed by Tomi Manninen
- <tomi.manninen@hut.fi> and was based on the original PMS program. It
- provides a fairly complete and flexible node capability that is easily
- configured. It allows users once they are connected to make Telnet,
- NetRom, Rose, and AX.25 connections out and to obtain various sorts of
- information such as Finger, Nodes and Heard lists etc. You can
- configure the node to execute any Linux command you wish fairly
- simply.
-
- The node would normally be invoked from the ax25d program although it
- is also capable of being invoked from the TCP/IP inetd program to
- allow users to telnet to your machine and obtain access to it, or by
- running it from the command line.
-
- 13.1. Creating the /etc/ax25/node.conf file.
-
- The node.conf file is where the main configuration of the node takes
- place. It is a simple text file and its format is as follows:
-
- # /etc/ax25/node.conf
- # configuration file for the node(8) program.
- #
- # Lines beginning with '#' are comments and are ignored.
-
- # Hostname
- # Specifies the hostname of the node machine
- hostname radio.gw.vk2ktj.ampr.org
-
- # Local Network
- # allows you to specify what is consider 'local' for the
- # purposes of permission checking using nodes.perms.
- localnet 44.136.8.96/29
-
- # Hide Ports
- # If specified allows you to make ports invisible to users. The
- # listed ports will not be listed by the (P)orts command.
- hiddenports rose netrom
-
- # Node Identification.
- # this will appear in the node prompt
- NodeId LINUX:VK2KTJ-9
-
- # NetRom port
- # This is the name of the netrom port that will be used for
- # outgoing NetRom connections from the node.
- NrPort netrom
-
- # Node Idle Timeout
- # Specifies the idle time for connections to this node in seconds.
- idletimout 1800
-
- # Connection Idle Timeout
- # Specifies the idle timer for connections made via this node in
- # seconds.
- conntimeout 1800
-
- # Reconnect
- # Specifies whether users should be reconnected to the node
- # when their remote connections disconnect, or whether they
- # should be disconnected complete.
- reconnect on
-
- # Command Aliases
- # Provide a way of making complex node commands simple.
- alias CONV "telnet vk1xwt.ampr.org 3600"
- alias BBS "connect radio vk2xsb"
-
- # Externam Command Aliases
- # Provide a means of executing external commands under the node.
- # extcmd <cmdname> <flag> <userid> <command>
- # Flag == 1 is the only implemented function.
- # <command> is formatted as per ax25d.conf
- extcmd PMS 1 root /usr/sbin/pms pms -u %U -o VK2KTJ
-
- # Logging
- # Set logging to the system log. 3 is the noisiest, 0 is disabled.
- loglevel 3
-
- # The escape character
- # 20 = (Control-T)
- EscapeChar 20
-
- 13.2. Creating the /etc/ax25/node.perms file.
-
- The node allows you to assign permissions to users. These permissions
- allow you to determine which users should be allowed to make use of
- options such as the (T)elnet, and (C)onnect commands, for example, and
- which shouldn't. The node.perms file is where this information is
- stored and contains five key fields. For all fields an asterisk `*'
- character matches anything. This is useful for building default rules.
-
- user
- The first field is the callsign or user to which the permissions
- should apply. Any SSID value is ignored, so you should just
- place the base callsign here.
-
- method
- Each protocol or access method is also given permissions. For
- example you might allow users who have connected via AX.25 or
- NetRom to use the (C)onnect option, but prevent others, such as
- those who are telnet connected from a non-local node from having
- access to it. The second field therefore allows you to select
- which access method this permissions rule should apply to. The
- access methods allowed are:
-
- method description
- ------ -----------------------------------------------------------
- ampr User is telnet connected from an amprnet address (44.0.0.0)
- ax25 User connected by AX.25
- host User started node from command line
- inet user is telnet connected from a non-loca, non-ampr address.
- local User is telnet connected from a 'local' host
- netrom User connected by NetRom
- rose User connected by Rose
- * User connected by any means.
-
- port
- For AX.25 users you can control permissions on a port by port
- basis too if you choose. This allows you to determine what AX.25
- are allowed to do based on which of your ports they have
- connected to. The third field contains the port name if you are
- using this facility. This is useful only for AX.25 connections.
-
- password
- You may optionally configure the node so that it prompts users
- to enter a password when they connect. This might be useful to
- help protect specially configured users who have high authority
- levels. If the fourth field is set then its value will be the
- password that will be accepted.
-
- permissions
- The permissions field is the final field in each entry in the
- file. The permissions field is coded as a bit field, with each
- facility having a bit value which if set allows the option to be
- used and if not set prevents the facility being used. The list
- of controllable facilities and their corresponding bit values
- are:
-
- value description
- ----- -------------------------------------------------
- 1 Login allowed.
- 2 AX25 (C)onnects allowed.
- 4 NetRom (C)onnects allowed.
- 8 (T)elnet to local hosts allowed.
- 16 (T)elnet to amprnet (44.0.0.0) hosts allowed.
- 32 (T)elnet to non-local, non-amprnet hosts allowed.
- 64 Hidden ports allowed for AX.25 (C)onnects.
- 128 Rose (C)onnects allowed.
-
- To code the permissions value for a rule, simply take each of the
- permissions you want that user to have and add their values
- together. The resulting number is what you place in field five.
-
- A sample nodes.perms might look like:
-
- # /etc/ax25/node.perms
- #
- # The node operator is VK2KTJ, has a password of 'secret' and
- # is allowed all permissions by all connection methods
- vk2ktj * * secret 255
-
- # The following users are banned from connecting
- NOCALL * * * 0
- PK232 * * * 0
- PMS * * * 0
-
- # INET users are banned from connecting.
- * inet * * 0
-
- # AX.25, NetRom, Local, Host and AMPR users may (C)onnect and (T)elnet
- # to local and ampr hosts but not to other IP addresses.
- * ax25 * * 159
- * netrom * * 159
- * local * * 159
- * host * * 159
- * ampr * * 159
-
- 13.3. Configuring node to run from ax25d
-
- The node program would normally be run by the ax25d program. To do
- this you need to add appropriate rules to the /etc/ax25/ax25d.conf
- file. In my configuration I wanted users to have a choice of either
- connecting to the node or connecting to other services. ax25d allows
- you to do this by cleverly creating creating port aliases. For
- example, given the ax25d configuration presented above, I want to
- configure node so that all users who connect to VK2KTJ-1 are given the
- node. To do this I add the following to my /etc/ax25/ax25d.conf file:
-
- [vk2ktj-1 via radio]
- default * * * * * 0 root /usr/sbin/node node
-
- This says that the Linux kernel code will answer any connection
- requests for the callsign `VK2KTJ-1' heard on the AX.25 port named
- `radio', and will cause the node program to be run.
-
- 13.4. Configuring node to run from inetd
-
- If you want users to be able to telnet a port on your machine and
- obtain access to the node you can go this fairly easily. The first
- thing to decide is what port users should connect to. In this example
- I've arbitrarily chosen port 4000, though Tomi gives details on how
- you could replace the normal telnet daemon with the node in his
- documentation.
-
- You need to modify two files.
-
- To /etc/services you should add:
-
- node 3694/tcp #OH2BNS's node software
-
- and to /etc/inetd.conf you should add:
-
- node stream tcp nowait root /usr/sbin/node node
-
- When this is done, and you have restarted the inetd program any user
- who telnet connects to port 3694 of your machine will be prompted to
- login and if configured, their password and then they will be con¡
- nected to the node.
-
- 14. Configuring axspawn.
-
- The axspawn program is a simple program that allows AX.25 stations who
- connect to be logged in to your machine. It may be invoked from the
- ax25d program as described above in a manner similar to the node
- program. To allow a user to log in to your machine you should add a
- line similar to the following into your /etc/ax25/ax25d.conf file:
-
- default * * * * * 1 root /usr/sbin/axspawn axspawn %u
-
- If the line ends in the + character then the connecting user must hit
- return before they will be allowed to login. The default is to not
- wait. Any individual host configurations that follow this line will
- have the axspawn program run when they connect. When axspawn is run it
- first checks that the command line argument it is supplied is a legal
- callsign, strips the SSID, then it checks that /etc/passwd file to see
- if that user has an account configured. If there is an account, and
- the password is either "" (null) or + then the user is logged in, if
- there is anything in the password field the user is prompted to enter
- a password. If there is not an existing account in the /etc/passwd
- file then axspawn may be configured to automatically create one.
-
- 14.1. Creating the /etc/ax25/axspawn.conf file.
-
- You can alter the behaviour of axspawn in various ways by use of the
- /etc/ax25/axspawn.conf file. This file is formatted as follows:
-
- # /etc/ax25/axspawn.conf
- #
- # allow automatic creation of user accounts
- create yes
- #
- # guest user if above is 'no' or everything else fails. Disable with "no"
- guest no
- #
- # group id or name for autoaccount
- group ax25
- #
- # first user id to use
- first_uid 2001
- #
- # maximum user id
- max_uid 3000
- #
- # where to add the home directory for the new users
- home /home/ax25
- #
- # user shell
- shell /bin/bash
- #
- # bind user id to callsign for outgoing connects.
- associate yes
-
- The eight configurable characteristics of axspawn are as follows:
-
- # indicates a comment.
-
- create
- if this field is set to yes then axspawn will attempt to
- automatically create a user account for any user who connects
- and does not already have an entry in the /etc/passwd file.
-
- guest
- this field names the login name of the account that will be used
- for people who connect who do not already have accounts if
- create is set to no. This is usually ax25 or guest.
-
- group
- this field names the group name that will be used for any users
- who connect and do not already have an entry in the /etc/passwd
- file.
-
- first_uid
- this is the number of the first userid that will be
- automatically created for new users.
-
- max_uid
- this is the maximum number that will be used for the userid of
- new users.
-
- home
- this is the home (login) directory of new users.
-
- shell
- this is the login shell of any new users.
-
- associate
- this flag indicates whether outgoing AX.25 connections made by
- this user after they login will use their own callsign, or your
- stations callsign.
-
- 15. Configuring the pms
-
- The pms program is an implementation of a simple personal message
- system. It was originally written by Alan Cox. Dave Brown, N2RJT,
- <dcb@vectorbd.com> has taken on further development of it. At present
- it is still very simple, supporting only the ability to send mail to
- the owner of the system and to obtain some limited system information
- but Dave is working to expand its capability to make it more useful.
-
- After that is done there are a couple of simple files that you should
- create that give users some information about the system and then you
- need to add appropriate entries into the ax25d.conf file so that
- connected users are presented with the PMS.
-
- 15.1. Create the /etc/ax25/pms.motd file.
-
- The /etc/ax25/pms.motd file contains the `message of the day' that
- users will be presented with after they connect and receive the usual
- BBS id header. The file is a simple text file, any text you include in
- this file will be sent to users.
-
- 15.2. Create the /etc/ax25/pms.info file.
-
- The /etc/ax25/pms.info file is also a simple text file in which you
- would put more detailed information about your station or
- configuration. This file is presented to users in response to their
- issuing of the Info command from the PMS> prompt.
-
- 15.3. Associate AX.25 callsigns with system users.
-
- When a connected user sends mail to an AX.25 callsign, the pms expects
- that callsign to be mapped, or associated with a real system user on
- your machine. This is described in a section of its own.
-
- 15.4. Add the PMS to the /etc/ax25/ax25d.conf file.
-
- Adding the pms to your ax25d.conf file is very simple. There is one
- small thing you need to think about though. Dave has added command
- line arguments to the PMS to allow it to handle a number of different
- text end-of-line conventions. AX.25 and NetRom by convention expect
- the end-of-line to be carriage return, linefeed while the standard
- unix end-of-line is just newline. So, for example, if you wanted to
- add an entry that meant that the default action for a connection
- received on an AX.25 port is to start the PMS then you would add a
- line that looked something like:
-
- default 1 10 5 100 5 0 root /usr/sbin/pms pms -a -o vk2ktj
-
- This simply runs the pms program, telling it that it is an AX.25
- connection it is connected to and that the PMS owner is vk2ktj. Check
- the man page for what you should specify for other connection methods.
-
- 15.5. Test the PMS.
-
- To test the PMS, you can try the following command from the command
- line:
-
- # /usr/sbin/pms -u vk2ktj -o vk2ktj
-
- Substitute your own callsign for mine and this will run the pms,
- telling it that it is to use the unix end-of-line convention, and that
- user logging in is vk2ktj. You can do all the things connected users
- can.
-
- Additionally you might try getting some other node to connect to you
- to confirm that your ax25d.conf configuration works.
-
- 16. Configuring the user_call programs.
-
- The `user_call' programs are really called: ax25_call and netrom_call.
- They are very simple programs designed to be called from ax25d to
- automate network connections to remote hosts. They may of course be
- called from a number of other places such as shell scripts or other
- daemons such as the node program.
-
- They are like a very simple call program. They don't do any meddling
- with the data at all, so the end of line handling you'll have to worry
- about yourself.
-
- Let's start with an example of how you might use them. Imagine you
- have a small network at home and that you have one linux machine
- acting as your Linux radio gateway and another machine, lets say a BPQ
- node connected to it via an ethernet connection.
-
- Normally if you wanted radio users to be able to connect to the BPQ
- node they would either have to digipeat through your linux node, or
- connect to the node program on your linux node and then connect from
- it. The ax25_call program can simplify this if it is called from the
- ax25d program.
-
- Imagine the BPQ node has the callsign VK2KTJ-9 and that the linux
- machine has the AX.25/ethernet port named `bpq'. Let us also imagine
- the Linux gateway machine has a radio port called `radio'.
-
- An entry in the /etc/ax25/ax25d.conf that looked like:
-
- [VK2KTJ-1 via radio]
- default * * * * * * *
- root /usr/sbin/ax25_call ax25_call bpq %u vk2ktj-9
-
- would enable users to connect direct to `VK2KTJ-1' which would actu¡
- ally be the Linux ax25d daemon and then be automatically switched to
- an AX.25 connection to `VK2KTJ-9' via the `bpq' interface.
-
- There are all sorts of other possible configurations that you might
- try. The `netrom_call' and `rose_call' utilities work in similar
- ways. One amateur has used this utility to make connections to a
- remote BBS easier. Normally the users would have to manually enter a
- long connection string to make the call so he created an entry that
- made the BBS appear as though it were on the local network by having
- his ax25d proxy the connection to the remote machine.
-
- 17. Configuring the Rose Uplink and Downlink commands
-
- If you are familiar with the ROM based Rose implementation you will be
- familiar with the method by which AX.25 users make calls across a Rose
- network. If a users local Rose node has the callsign VK2KTJ-5 and the
- AX.25 user wants to connect to VK5XXX at remote Rose node 5050882960
- then they would issue the command:
-
- c vk5xxx v vk2ktj-5 5050 882960
-
- At the remote node, VK5XXX would see an incoming connection with the
- local AX.25 users callsign and being digipeated via the remote Rose
- nodes callsign.
-
- The Linux Rose implementation does not support this capability in the
- kernel, but there are two application programs called rsuplnk and
- rsdwnlnk which perform this function.
-
- 17.1. Configuring a Rose downlink
-
- To configure your Linux machine to accept a Rose connection and
- establish an AX.25 connection to any destination callsign that is not
- being listened for on your machine you need to add an entry to your
- /etc/ax25/ax25d.conf file. Normally you would configure this entry to
- be the default behaviour for incoming Rose connections. For example
- you might have Rose listeners operating for destinations like NODE-0
- or HEARD-0 that you wish to handle locally, but for all other
- destination calls you may want to pass them to the rsdwnlink command
- and assume they are AX.25 users.
-
- A typical configuration would look like:
-
- #
- {* via rose}
- NOCALL * * * * * * L
- default * * * * * * - root /usr/sbin/rsdwnlnk rsdwnlnk 4800 vk2ktj-5
- #
-
- With this configuration any user who established a Rose connection to
- your Linux nodes address with a destination call of something that you
- were not specifically listening for would be converted into an AX.25
- connection on the AX.25 port named 4800 with a digipeater path of
- VK2KTJ-5.
-
- 17.2. Configuring a Rose uplink
-
- To configure your Linux machine to accept AX.25 connections in the
- same way that a ROM Rose node would you must add an entry into your
- /etc/ax25/ax25d.conf file that looks similar to the following:
-
- #
- [VK2KTJ-5* via 4800]
- NOCALL * * * * * * L
- default * * * * * * - root /usr/sbin/rsuplnk rsuplnk rose
- #
-
- Note the special syntax for the local callsign. The `*' character
- indicates that the application should be invoked if the callsign is
- heard in the digipeater path of a connection.
-
- This configuration would allow an AX.25 user to establish Rose calls
- using the example connect sequence presented in the introduction.
- Anybody attempting to digipeat via VK2KTJ-5 on the AX.25 port named
- 4800 would be handled by the rsuplnk command.
-
- 18. Associating AX.25 callsigns with Linux users.
-
- There are a number of situations where it is highly desirable to
- associate a callsign with a linux user account. One example might be
- where a number of amateur radio operators share the same linux machine
- and wish to use their own callsign when making calls. Another is the
- case of PMS users wanting to talk to a particular user on your
- machine.
-
- The AX.25 software provides a means of managing this association of
- linux user account names with callsigns. We've mentioned it once
- already in the PMS section, but I'm spelling it out here to be sure
- you don't miss it.
-
- You make the association with the axparms command. An example looks
- like:
-
- # axparms -assoc vk2ktj terry
-
- This command associates that AX.25 callsign vk2ktj with the user terry
- on the machine. So, for example, any mail for vk2ktj on the pms will
- be sent to Linux account terry.
-
- Remember to put these associations into your rc file so that they are
- available each time your reboot.
-
- Note you should never associate a callsign with the root account as
- this can cause configuration problems in other programs.
-
- 19. The /proc/ file system entries.
-
- The /proc filesystem contains a number of files specifically related
- to the AX25 and NetRom kernel software. These files are normally used
- by the AX52 utilities, but they are plainly formatted so you may be
- interested in reading them. The format is fairly easily understood so
- I don't think much explanation will be necessary.
-
- /proc/net/arp
- contains the list of Address Resolution Protocol mappings of IP
- addresses to MAC layer protocol addresses. These can can AX.25,
- ethernet or some other MAC layer protocol.
-
- /proc/net/ax25
- contains a list of AX.25 sockets opened. These might be
- listening for a connection, or active sessions.
-
- /proc/net/ax25_bpqether
- contains the AX25 over ethernet BPQ style callsign mappings.
-
- /proc/net/ax25_calls
- contains the linux userid to callsign mappings set my the
- axparms -assoc command.
-
- /proc/net/ax25_route
- contains AX.25 digipeater path information.
-
- /proc/net/nr
- contains a list of NetRom sockets opened. These might be
- listening for a connection, or active sessions.
-
- /proc/net/nr_neigh
- contains information about the NetRom neighbours known to the
- NetRom software.
-
- /proc/net/nr_nodes
- contains information about the NetRom nodes known to the NetRom
- software.
-
- /proc/net/rose
- contains a list of Rose sockets opened. These might be listening
- for a connection, or active sessions.
-
- /proc/net/rose_nodes
- contains a mapping of Rose destinations to Rose neighbours.
-
- /proc/net/rose_neigh
- contains a list of known Rose neighbours.
-
- /proc/net/rose_routes
- contains a list of all established Rose connections.
-
- 20. AX.25, NetRom, Rose network programming.
-
- Probably the biggest advantage of using the kernel based
- implementations of the amateur packet radio protocols is the ease with
- which you can develop applications and programs to use them.
-
- While the subject of Unix Network Programming is outside the scope of
- this document I will describe the elementary details of how you can
- make use of the AX.25, NetRom and Rose protocols within your software.
-
- 20.1. The address families.
-
- Network programming for AX.25, NetRom and Rose is quite similar to
- programming for TCP/IP under Linux. The major differences being the
- address families used, and the address structures that need to be
- mangled into place.
-
- The address family names for AX.25, NetRom and Rose are AF_AX25,
- AF_NETROM and AF_ROSE respectively.
-
- 20.2. The header files.
-
- You must always include the `ax25.h' header file, and also the
- `netrom.h' or `rose.h' header files if you are dealing with those
- protocols. Simple top level skeletons would look something like the
- following:
-
- For AX.25:
-
- #include <ax25.h>
- int s, addrlen = sizeof(struct full_sockaddr_ax25);
- struct full_sockaddr_ax25 sockaddr;
- sockaddr.fsa_ax25.sax25_family = AF_AX25
-
- For NetRom:
-
- #include <ax25.h>
- #include <netrom.h>
- int s, addrlen = sizeof(struct full_sockaddr_ax25);
- struct full_sockaddr_ax25 sockaddr;
- sockaddr.fsa_ax25.sax25_family = AF_NETROM;
-
- For Rose:
-
- #include <ax25.h>
- #include <rose.h>
- int s, addrlen = sizeof(struct sockaddr_rose);
- struct sockaddr_rose sockaddr;
- sockaddr.srose_family = AF_ROSE;
-
- 20.3. Callsign mangling and examples.
-
- There are routines within the lib/ax25.a library built in the AX25
- utilities package that manage the callsign conversions for you. You
- can write your own of course if you wish.
-
- The user_call utilities are excellent examples from which to work. The
- source code for them is included in the AX25 utilities package. If
- you spend a little time working with those you will soon see that
- ninety percent of the work is involved in just getting ready to open
- the socket. Actually making the connection is easy, the preparation
- takes time.
-
- The example are simple enough to not be very confusing. If you have
- any questions, you should feel to direct them to the linux-hams
- mailing list and someone there will be sure to help you.
-
- 21. Some sample configurations.
-
- Following are examples of the most common types of configurations.
- These are guides only as there are as many ways of configuring your
- network as there are networks to configure, but they may give you a
- start.
-
- 21.1. Small Ethernet LAN with Linux as a router to Radio LAN
-
- Many of you may have small local area networks at home and want to
- connect the machines on that network to your local radio LAN. This is
- the type of configuration I use at home. I arranged to have a suitable
- block of addresses allocated to me that I could capture in a single
- route for convenience and I use these on my Ethernet LAN. Your local
- IP coordinator will assist you in doing this if you want to try it as
- well. The addresses for the Ethernet LAN form a subset of the radio
- LAN addresses. The following configuration is the actual one for my
- linux router on my network at home:
-
- . . . . . .
- --- .
- | Network /---------\ . Network
- | 44.136.8.96/29| | . 44.136.8/24 \ | /
- | | Linux | . \|/
- | | | . |
- | eth0 | Router | . /-----\ /----------\ |
- |---------------| |-----| TNC |----| Radio |---/
- | 44.136.8.97 | and | . \-----/ \----------/
- | | | sl0
- | | Server | 44.136.8.5
- | | | .
- | | | .
- | \_________/ .
- --- . . . . . .
-
- #!/bin/sh
- # /etc/rc.net
- # This configuration provides one KISS based AX.25 port and one
- # Ethernet device.
-
- echo "/etc/rc.net"
- echo " Configuring:"
-
- echo -n " loopback:"
- /sbin/ifconfig lo 127.0.0.1
- /sbin/route add 127.0.0.1
- echo " done."
-
- echo -n " ethernet:"
- /sbin/ifconfig eth0 44.136.8.97 netmask 255.255.255.248 \
- broadcast 44.136.8.103 up
- /sbin/route add 44.136.8.97 eth0
- /sbin/route add -net 44.136.8.96 netmask 255.255.255.248 eth0
- echo " done."
-
- echo -n " AX.25: "
- kissattach -i 44.136.8.5 -m 512 /dev/ttyS1 4800
- ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.8.255
- route add -host 44.136.8.5 sl0
- route add -net 44.136.8.0 window 1024 sl0
-
- echo -n " Netrom: "
- nrattach -i 44.136.8.5 netrom
-
- echo " Routing:"
- /sbin/route add default gw 44.136.8.68 window 1024 sl0
- echo " default route."
- echo done.
-
- # end
-
- /etc/ax25/axports
-
- # name callsign speed paclen window description
- 4800 VK2KTJ-0 4800 256 2 144.800 MHz
-
- /etc/ax25/nrports
-
- # name callsign alias paclen description
- netrom VK2KTJ-9 LINUX 235 Linux Switch Port
-
- /etc/ax25/nrbroadcast
-
- # ax25_name min_obs def_qual worst_qual verbose
- 4800 1 120 10 1
-
- ╖ You must have IP_FORWARDING enabled in your kernel.
-
- ╖ The AX.25 configuration files are pretty much those used as
- examples in the earlier sections, refer to those where necessary.
-
- ╖ I've chosen to use an IP address for my radio port that is not
- within my home network block. I needn't have done so, I could have
- easily used 44.136.8.97 for that port too.
-
- ╖ 44.136.8.68 is my local IPIP encapsulated gateway and hence is
- where I point my default route.
-
- ╖ Each of the machines on my Ethernet network have a route:
-
- route add -net 44.0.0.0 netmask 255.0.0.0 \
- gw 44.136.8.97 window 512 mss 512 eth0
-
- The use of the mss and window parameters means that I can get optimum
- performance from both local Ethernet and radio based connections.
-
- ╖ I also run my smail, http, ftp and other daemons on the router
- machine so that it needs to be the only machine to provide others
- with facilities.
-
- ╖ The router machine is a lowly 386DX20 with a 20Mb harddrive and a
- very minimal linux configuration.
-
- 21.2. IPIP encapsulated gateway configuration.
-
- Linux is now very commonly used for TCP/IP encapsulated gateways
- around the world. The new tunnel driver supports multiple encapsulated
- routes and makes the older ipip daemon obsolete.
-
- A typical configuration would look similar to the following.
-
- . . . . . .
- --- .
- | Network /---------\ . Network
- | 154.27.3/24 | | . 44.136.16/24 \ | /
- | | Linux | . \|/
- | | | . |
- | eth0 | IPIP | . /-----\ /----------\ |
- ---|---------------| |-----| TNC |----| Radio |---/
- | 154.27.3.20 | Gateway | . \-----/ \----------/
- | | | sl0
- | | | 44.136.16.1
- | | | .
- | | | .
- | \_________/ .
- --- . . . . . .
-
- The configuration files of interest are:
-
- # /etc/rc.net
- # This file is a simple configuration that provides one KISS AX.25
- # radio port, one Ethernet device, and utilises the kernel tunnel driver
- # to perform the IPIP encapsulation/decapsulation
- #
- echo "/etc/rc.net"
- echo " Configuring:"
- #
- echo -n " loopback:"
- /sbin/ifconfig lo 127.0.0.1
- /sbin/route add 127.0.0.1
- echo " done."
- #
- echo -n " ethernet:"
- /sbin/ifconfig eth0 154.27.3.20 netmask 255.255.255.0 \
- broadcast 154.27.3.255 up
- /sbin/route add 154.27.3.20 eth0
- /sbin/route add -net 154.27.3.0 netmask 255.255.255.0 eth0
- echo " done."
- #
- echo -n " AX.25: "
- kissattach -i 44.136.16.1 -m 512 /dev/ttyS1 4800
- /sbin/ifconfig sl0 netmask 255.255.255.0 broadcast 44.136.16.255
- /sbin/route add -host 44.136.16.1 sl0
- /sbin/route add -net 44.136.16.0 netmask 255.255.255.0 window 1024 sl0
- #
- echo -n " tunnel:"
- /sbin/ifconfig tunl0 44.136.16.1 mtu 512 up
- #
- echo done.
- #
- echo -n "Routing ... "
- source /etc/ipip.routes
- echo done.
- #
- # end.
-
- and:
-
- # /etc/ipip.routes
- # This file is generated using the munge script
- #
- /sbin/route add -net 44.134.8.0 netmask 255.255.255.0 tunl0 gw 134.43.26.1
- /sbin/route add -net 44.34.9.0 netmask 255.255.255.0 tunl0 gw 174.84.6.17
- /sbin/route add -net 44.13.28.0 netmask 255.255.255.0 tunl0 gw 212.37.126.3
- ...
- ...
- ...
-
- /etc/ax25/axports
-
- # name callsign speed paclen window description
- 4800 VK2KTJ-0 4800 256 2 144.800 MHz
-
- Some points to note here are:
-
- ╖ The new tunnel driver uses the gw field in the routing table in
- place of the pointopoint parameter to specify the address of the
- remote IPIP gateway. This is why it now supports multiple routes
- per interface.
-
- ╖ You can configure two network devices with the same address. In
- this example both the sl0 and the tunl0 devices have been
- configured with the IP address of the radio port. This is done so
- that the remote gateway sees the correct address from your gateway
- in encapsulated datagrams sent to it.
-
- ╖ The route commands used to specify the encapsulated routes can be
- automatically generated by a modified version of the munge script.
- This is included below. The route commands would then be written to
- a separate file and read in using the bash source /etc/ipip.routes
- command (assuming you called the file with the routing commands
- /etc/ipip.routes) as illustrated. The source file must be in the
- NOS route command format.
-
- ╖ Note the use of the window argument on the route command. Setting
- this parameter to an appropriate value improves the performance of
- your radio link.
-
- The new tunnel-munge script:
-
- #!/bin/sh
- #
- # From: Ron Atkinson <n8fow@hamgate.cc.wayne.edu>
- #
- # This script is basically the 'munge' script written by Bdale N3EUA
- # for the IPIP daemon and is modified by Ron Atkinson N8FOW. It's
- # purpose is to convert a KA9Q NOS format gateways route file
- # (usually called 'encap.txt') into a Linux routing table format
- # for the IP tunnel driver.
- #
- # Usage: Gateway file on stdin, Linux route format file on stdout.
- # eg. tunnel-munge < encap.txt > ampr-routes
- #
- # NOTE: Before you use this script be sure to check or change the
- # following items:
- #
- # 1) Change the 'Local routes' and 'Misc user routes' sections
- # to routes that apply to your own area (remove mine please!)
- # 2) On the fgrep line be sure to change the IP address to YOUR
- # gateway Internet address. Failure to do so will cause serious
- # routing loops.
- # 3) The default interface name is 'tunl0'. Make sure this is
- # correct for your system.
-
- echo "#"
- echo "# IP tunnel route table built by $LOGNAME on `date`"
- echo "# by tunnel-munge script v960307."
- echo "#"
- echo "# Local routes"
- echo "route add -net 44.xxx.xxx.xxx netmask 255.mmm.mmm.mmm dev sl0"
- echo "#"
- echo "# Misc user routes"
- echo "#"
- echo "# remote routes"
-
- fgrep encap | grep "^route" | grep -v " XXX.XXX.XXX.XXX" | \
- awk '{
- split($3, s, "/")
- split(s[1], n,".")
- if (n[1] == "") n[1]="0"
- if (n[2] == "") n[2]="0"
- if (n[3] == "") n[3]="0"
- if (n[4] == "") n[4]="0"
- if (s[2] == "1") mask="128.0.0.0"
- else if (s[2] == "2") mask="192.0.0.0"
- else if (s[2] == "3") mask="224.0.0.0"
- else if (s[2] == "4") mask="240.0.0.0"
- else if (s[2] == "5") mask="248.0.0.0"
- else if (s[2] == "6") mask="252.0.0.0"
- else if (s[2] == "7") mask="254.0.0.0"
- else if (s[2] == "8") mask="255.0.0.0"
- else if (s[2] == "9") mask="255.128.0.0"
- else if (s[2] == "10") mask="255.192.0.0"
- else if (s[2] == "11") mask="255.224.0.0"
- else if (s[2] == "12") mask="255.240.0.0"
- else if (s[2] == "13") mask="255.248.0.0"
- else if (s[2] == "14") mask="255.252.0.0"
- else if (s[2] == "15") mask="255.254.0.0"
- else if (s[2] == "16") mask="255.255.0.0"
- else if (s[2] == "17") mask="255.255.128.0"
- else if (s[2] == "18") mask="255.255.192.0"
- else if (s[2] == "19") mask="255.255.224.0"
- else if (s[2] == "20") mask="255.255.240.0"
- else if (s[2] == "21") mask="255.255.248.0"
- else if (s[2] == "22") mask="255.255.252.0"
- else if (s[2] == "23") mask="255.255.254.0"
- else if (s[2] == "24") mask="255.255.255.0"
- else if (s[2] == "25") mask="255.255.255.128"
- else if (s[2] == "26") mask="255.255.255.192"
- else if (s[2] == "27") mask="255.255.255.224"
- else if (s[2] == "28") mask="255.255.255.240"
- else if (s[2] == "29") mask="255.255.255.248"
- else if (s[2] == "30") mask="255.255.255.252"
- else if (s[2] == "31") mask="255.255.255.254"
- else mask="255.255.255.255"
-
- if (mask == "255.255.255.255")
- printf "route add -host %s.%s.%s.%s gw %s dev tunl0\n"\
- ,n[1],n[2],n[3],n[4],$5
- else
- printf "route add -net %s.%s.%s.%s gw %s netmask %s dev tunl0\n"\
- ,n[1],n[2],n[3],n[4],$5,mask
- }'
-
- echo "#"
- echo "# default the rest of amprnet via mirrorshades.ucsd.edu"
- echo "route add -net 44.0.0.0 gw 128.54.16.18 netmask 255.0.0.0 dev tunl0"
- echo "#"
- echo "# the end"
-
- 21.3. AXIP encapsulated gateway configuration
-
- Many Amateur Radio Internet gateways encapsulate AX.25, NetRom and
- Rose in addition to tcp/ip. Encapsulation of AX.25 frames within IP
- datagrams is described in RFC-1226 by Brian Kantor. Mike Westerhof
- wrote an implementation of an AX.25 encapsulation daemon for unix in
- 1991. The ax25-utils package includes a marginally enhanced version of
- it for Linux.
-
- An AXIP encapsulation program accepts AX.25 frames at one end, looks
- at the destination AX.25 address to determine what IP address to send
- them to, encapsulates them in a tcp/ip datagram and then transmits
- them to the appropriate remote destination. It also accepts tcp/ip
- datagrams that contain AX.25 frames, unwraps them and processes them
- as if it had received them directly from an AX.25 port. To distinguish
- IP datagrams containing AX.25 frames from other IP datagrams which
- don't, AXIP datagrams are coded with a protocol id of 4 (or 94 which
- is now deprecated). This process is described in RFC-1226.
-
- The ax25ipd program included in the ax25-utils package presents itself
- as a program supporting a KISS interface across which you pass AX.25
- frames, and an interface into the tcp/ip protocols. It is configured
- with a single configuration file called /etc/ax25/ax25ipd.conf.
-
- 21.3.1. AXIP configuration options.
-
- The ax25ipd program has two major modes of operation. "digipeater"
- mode and "tnc" mode. In "tnc" mode the daemon is treated as though it
- were a kiss TNC, you pass KISS encapsulated frames to it and it will
- transmit them, this is the usual configuration. In "digipeater" mode,
- you treat the daemon as though it were an AX.25 digipeater. There are
- subtle differences between these modes.
-
- In the configuration file you configure "routes" or mappings between
- destination AX.25 callsigns and the IP addresses of the hosts that you
- want to send the AX.25 packets too. Each route has options which will
- be explained later.
- Other options that are configured here are
-
- the tty that the ax25ipd daemon will open and its speed (usually one
- end of a pipe)
-
- what callsign you want to use in "digipeater" mode
-
- beacon interval and text
-
- whether you want to encapsulate the AX.25 frames in IP datagrams or in
- UDP/IP datagrams. Nearly all AXIP gateways use IP encapsulation, but
- some gateways are behind firewalls that will not allow IP with the
- AXIP protocol id to pass and are forced to use UDP/IP. Whatever you
- choose must match what the tcp/ip host at the other end of the link is
- using.
-
- 21.3.2. A typical /etc/ax25/ax25ipd.conf file.
-
- #
- # ax25ipd configuration file for station floyd.vk5xxx.ampr.org
- #
- # Select axip transport. 'ip' is what you want for compatibility
- # with most other gateways.
- #
- socket ip
- #
- # Set ax25ipd mode of operation. (digi or tnc)
- #
- mode tnc
- #
- # If you selected digi, you must define a callsign. If you selected
- # tnc mode, the callsign is currently optional, but this may change
- # in the future! (2 calls if using dual port kiss)
- #
- #mycall vk5xxx-4
- #mycall2 vk5xxx-5
- #
- # In digi mode, you may use an alias. (2 for dual port)
- #
- #myalias svwdns
- #myalias2 svwdn2
- #
- # Send an ident every 540 seconds ...
- #
- #beacon after 540
- #btext ax25ip -- tncmode rob/vk5xxx -- Experimental AXIP gateway
- #
- # Serial port, or pipe connected to a kissattach in my case
- #
- device /dev/ttyq0
- #
- # Set the device speed
- #
- speed 9600
- #
- # loglevel 0 - no output
- # loglevel 1 - config info only
- # loglevel 2 - major events and errors
- # loglevel 3 - major events, errors, and AX25 frame trace
- # loglevel 4 - all events
- # log 0 for the moment, syslog not working yet ...
- #
- loglevel 2
- #
- # If we are in digi mode, we might have a real tnc here, so use param to
- # set the tnc parameters ...
- #
- #param 1 20
- #
- # Broadcast Address definition. Any of the addresses listed will be forwarded
- # to any of the routes flagged as broadcast capable routes.
- #
- broadcast QST-0 NODES-0
- #
- # ax.25 route definition, define as many as you need.
- # format is route (call/wildcard) (ip host at destination)
- # ssid of 0 routes all ssid's
- #
- # route <destcall> <destaddr> [flags]
- #
- # Valid flags are:
- # b - allow broadcasts to be transmitted via this route
- # d - this route is the default route
- #
- route vk2sut-0 44.136.8.68 b
- route vk5xxx 44.136.188.221 b
- route vk2abc 44.1.1.1
- #
- #
-
- 21.3.3. Running ax25ipd
-
- Create your /etc/ax25/axports entry:
-
- # /etc/ax25/axports
- #
- axip VK2KTJ-13 9600 256 AXIP port
- #
-
- Run the kissattach command to create that port:
-
- /usr/sbin/kissattach /dev/ptyq0 axip
-
- Run the ax25ipd program:
-
- /usr/sbin/ax25ipd &
-
- Test the AXIP link:
-
- call axip vk5xxx
-
- 21.3.4. Some notes about the routes and route flags
-
- The "route" command is where you specify where you want your AX.25
- packets encapsulated and sent to. When the ax25ipd daemon receives a
- packet from its interface, it compares the destination callsign with
- each of the callsigns in its routing table. If if finds a match then
- the ax.25 packet is encapsulated in an IP datagram and then
- transmitted to the host at the specified IP address.
-
- There are two flags you can add to any of the route commands in the
- ax25ipd.conf file. The two flags are:
-
- b traffic with a destination address matching any of those on the
- list defined by the "broadcast" keyword should be transmitted
- via this route.
-
- d any packets not matching any route should be transmitted via
- this route.
-
- The broadcast flag is very useful, as it enables informations that is
- normally destined for all stations to a number of AXIP destinations.
- Normally axip routes are point-to-point and unable to handle
- 'broadcast' packets.
-
- 21.4. Linking NOS and Linux using a pipe device
-
- Many people like to run some version of NOS under Linux because it has
- all of the features and facilities they are used to. Most of those
- people would also like to have the NOS running on their machine
- capable of talking to the Linux kernel so that they can offer some of
- the linux capabilities to radio users via NOS.
-
- Brandon S. Allbery, KF8NH, contributed the following information to
- explain how to interconnect the NOS running on a Linux machine with
- the kernel code using the Linux pipe device.
-
- Since both Linux and NOS support the slip protocol it is possible to
- link the two together by creating a slip link. You could do this by
- using two serial ports with a loopback cable between them, but this
- would be slow and costly. Linux provides a feature that many other
- Unix-like operating systems provide called `pipes'. These are special
- pseudo devices that look like a standard tty device to software but in
- fact loopback to another pipe device. To use these pipes the first
- program must open the master end of the pipe, and the open then the
- second program can open the slave end of the pipe. When both ends are
- open the programs can communicate with each other simply by writing
- characters to the pipes in the way they would if they were terminal
- devices.
-
- To use this feature to connect the Linux Kernel and a copy of NOS, or
- some other program you first must choose a pipe device to use. You can
- find one by looking in your /dev directory. The master end of the
- pipes are named: ptyq[1-f] and the slave end of the pipes are known
- as: ttyq[1-f]. Remember they come in pairs, so if you select
- /dev/ptyqf as your master end then you must use /dev/ttyqf as the
- slave end.
-
- Once you have chosen a pipe device pair to use you should allocate the
- master end to you linux kernel and the slave end to the NOS program,
- as the Linux kernel starts first and the master end of the pipe must
- be opened first. You must also remember that your Linux kernel must
- have a different IP address to your NOS, so you will need to allocate
- a unique address for it if you haven't already.
-
- You configure the pipe just as if it were a serial device, so to
- create the slip link from your linux kernel you can use commands
- similar to the following:
-
- # /sbin/slattach -s 38400 -p slip /dev/ptyqf &
- # /sbin/ifconfig sl0 broadcast 44.255.255.255 pointopoint 44.70.248.67 /
- mtu 1536 44.70.4.88
- # /sbin/route add 44.70.248.67 sl0
- # /sbin/route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.70.248.67
-
- In this example the Linux kernel has been given IP address 44.70.4.88
- and the NOS program is using IP address 44.70.248.67. The route
- command in the last line simply tells your linux kernel to route all
- datagrams for the amprnet via the slip link created by the slattach
- command. Normally you would put these commands into your
- /etc/rc.d/rc.inet2 file after all your other network configuration is
- complete so that the slip link is created automatically when you
- reboot. Note: there is no advantage in using cslip instead of slip as
- it actually reduces performance because the link is only a virtual one
- and occurs fast enough that having to compress the headers first takes
- longer than transmitting the uncompressed datagram.
-
- To configure the NOS end of the link you could try the following:
-
- # you can call the interface anything you want; I use "linux" for convenience.
- attach asy ttyqf - slip linux 1024 1024 38400
- route addprivate 44.70.4.88 linux
-
- These commands will create a slip port named `linux' via the slave end
- of the pipe device pair to your linux kernel, and a route to it to
- make it work. When you have started NOS you should be able to ping and
- telnet to your NOS from your Linux machine and vice versa. If not,
- double check that you have made no mistakes especially that you have
- the addresses configured properly and have the pipe devices around the
- right way.
-
- 22. Where do I find more information about .... ?
-
- Since this document assumes you already have some experience with
- packet radio and that this might not be the case I've collected a set
- of references to other information that you might find useful.
-
- 22.1. Packet Radio
-
- You can get general information about Packet Radio from these sites:
-
- American Radio Relay League <http://www.arrl.org/>,
-
- Radio Amateur Teleprinter Society <http://www.rats.org/>
-
- Tucson Amateur Packet Radio Group <http://www.tapr.org/>
-
- 22.2. Protocol Documentation
-
- AX.25, NetRom - Jonathon Naylor has collated a variety of documents
- that relate to the packet radio protocols themselves. This
- documentation has been packaged up into ax25-doc-1.0.tar.gz
- <ftp://ftp.pspt.fi/pub/ham/linux/ax25/ax25-doc-1.0.tar.gz>
-
- 22.3. Hardware Documentation
-
- Information on the PI2 Card is provided by the Ottawa Packet Radio
- Group <http://hydra.carleton.ca/>.
-
- Information on Baycom hardware is available at the Baycom Web Page
- <http://www.baycom.de/>.
-
- 23. Discussion relating to Amateur Radio and Linux.
-
- There are various places that discussion relating to Amateur Radio and
- Linux take place. They take place in the comp.os.linux.* newsgroups,
- they also take place on the HAMS list on vger.rutgers.edu. Other
- places where they are held include the tcp-group mailing list at
- ucsd.edu (the home of amateur radio TCP/IP discussions), and you might
- also try the #linpeople channel on the linuxnet irc network.
-
- To join the Linux linux-hams channel on the mail list server, send
- mail to:
-
- Majordomo@vger.rutgers.edu
-
- with the line:
-
- subscribe linux-hams
-
- in the message body. The subject line is ignored.
-
- The linux-hams mailing list is archived at:
-
- zone.pspt.fi <http://zone.pspt.fi/archive/linux-hams/> and
- zone.oh7rba.ampr.org <http://zone.oh7rba.ampr.org/archive/linux-
- hams/>. Please use the archives when you are first starting, because
- many common questions are answered there.
-
- To join the tcp-group send mail to:
-
- listserver@ucsd.edu
-
- with the line:
-
- subscribe tcp-group
-
- in the body of the text.
-
- Note: Please remember that the tcp-group is primarily for discussion
- of the use of advanced protocols, of which TCP/IP is one, in Amateur
- Radio. Linux specific questions should not ordinarily go there.
-
- 24. Acknowledgements.
-
- The following people have contributed to this document in one way or
- another, knowingly or unknowingly. In no particular order (as I find
- them): Jonathon Naylor, Thomas Sailer, Joerg Reuter, Ron Atkinson,
- Alan Cox, Craig Small, John Tanner, Brandon Allbery, Hans Alblas,
- Klaus Kudielka, Carl Makin.
-
- 25. Copyright.
-
- The AX25-HOWTO, information on how to install and configure some of
- the more important packages providing AX25 support for Linux.
- Copyright (c) 1996 Terry Dawson.
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or (at
- your option) any later version.
-
- This program is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the:
-
- Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
- USA.
-
-